Раздельная компиляция. Связывание const-переменных

@Mournful Max · Регистрация: 15.12.2015

Студворк — интернет-сервис помощи студентам

Не совсем понимаю процесс раздельной компиляции, или то как работает связывание const-переменных. Имеется три файла:

const_test.h

C++
1
2
3
4
5
6
7
#ifndef CONST_TEST_H_
#define CONST_TEST_H_
 
extern const int var;  // Это почему работает?
void func( void );
 
#endif  // CONST_TEST_H_

const_test.cpp

C++
1
2
3
4
5
6
7
8
9
#include <iostream>
#include "const_test.h"
 
const int var = 10;  // var имеет внутреннее связывание
 
void func( void )
{
    std::cout << &var << std::endl;
}

general.cpp

C++
1
2
3
4
5
6
7
8
#include <iostream>
#include "const_test.h"
 
int main()
{
    std::cout << &var << std::endl;
    func();
}

Собственно, почему это не вызывает ошибку компиляции? ( Компилировал в VS 2013 ) Разве не должен был произойти конфликт имен, когда в файл "const_test.cpp" включился файл "const_test.h"? Ведь, как я понимаю, extern const int var; -- это отличная переменная от const int var = 10;. Теперь немного изменим код:

const_test.h

C++
1
2
3
4
5
6
7
#ifndef CONST_TEST_H_
#define CONST_TEST_H_
 
extern int var;
void func( void );
 
#endif  // CONST_TEST_H_

const_test.cpp

C++
1
2
3
4
5
6
7
8
9
#include <iostream>
#include "const_test.h"
 
static int var = 10;
 
void func( void )
{
    std::cout << &var << std::endl;
}

general.cpp

C++
1
2
3
4
5
6
7
8
#include <iostream>
#include "const_test.h"
 
int main()
{
    std::cout << &var << std::endl;
    func();
}

Это уже ошибка. И это, по-моему нормально ( а по законам C++ нет?

), ведь инструкция extern int var; 1) порождает конфликт имен, 2) ссылается на несуществующую переменную ( ведь ни в одной единице трансляции не была объявлена внешняя int переменная с именем var ). В коде изменилось ( опять же таки, по моему мнению ) только то, что переменная var перестала быть const.

P.S.: Знаю, что не умею доступно объяснять, но у здешних жителей форума, как показывает практика, хорошо развиты телепатические способности, проблем возникнуть не должно

@УГнетатель · 08.09.2017, 21:44

Сообщение от hoggy

gcc вестимо лажает.

gcc лажает, у vc++ надо оптимизации отключить ...
Как тут не вспомнить известную русскую пословицу про танцора, которому всё мешает?

Добавлю сюда ещё clang
https://wandbox.org/permlink/VtaPdwC4zXeb0EHW

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <iostream>
 
template<class type>
const type* addr(const type& val)
{
    return &val;
}
 
int main()
{
    std::cout << addr(10) << '\n';
    std::cout << addr(11) << '\n';
    
    const int* addr_of_10 = addr(10);
    const int* addr_of_11 = addr(11);
    
    std::cout << *addr_of_10 << '\n';
    std::cout << *addr_of_11 << '\n';
}

Вывод:

Code
1
2
3
4
0x7ffc0875b8e4
0x7ffc0875b8e4
0
4208112

clang тоже лажает?

Сообщение от hoggy

хотите сказать, что код в #35 содержит UB?

Да вроде как не содержит.

Ferrari F1, кому прояснит? Мне-то всё ясно. ;)

@Mournful Max · 09.09.2017, 03:57 **[ТС]**

Сообщение от TheCalligrapher

А почему бы этому и не работать? Это обычное объявление const переменной с внешним связыванием.

Я начинаю понимать. Хорошо. Можно потолковать? Возьмем пустой проект, не касающийся предоставленных выше примеров. ( Объявления/определения переменных будут на уровне единицы трансляции )
1. Следующие две переменные, определенные таким образом: int var_1 = 0;, extern const int var_2 = 0; имеют внешнее связывание, верно?
2. Если мы хотим получить доступ к определенным выше переменным в соседней единице трансляции, мы должны написать следующее: extern int var_1; extern const int var_2;, верно?
3. Когда нам нужно определить переменную с внутренним связываем, мы поступаем так: static int var_3 = 0; ( в случае с обычной переменной ) и static const int var_4 = 0; или const int var_4 = 0; ( в случае с константной переменной ), верно?

Что мне остается непонятным:
Если определение static const int var = 0; эквивалентно определению const int var = 0; ( имеет внутреннее связывание по умолчанию ), то почему последнее ( const int var = 0; ) будет трактоваться как определение выше объявленной внешней extern const int var; ( если таковая имеется )? Получается, const int var = 0; двусмысленно? Двусмысленно в том смысле, что когда выше есть объявление ( extern const int var; ) внешней константной переменной с таким же именем, const int var = 0; трактуется как определение этой переменной. Если же выше нет никаких объявлений внешних переменных, const int var = 0; трактуется как определение независимой переменной с внутренним связыванием? Вот именно этот момент мне непонятен.

Добавлено через 1 минуту
Извиняюсь перед всеми за дотошность. Ну или тупость.
Я хочу освоить этот язык, поэтому должен добиться желаемого: узнать все как есть.

@TheCalligrapher · 09.09.2017, 04:13

Сообщение от Captain Maxee

1. Следующие две переменные, определенные таким образом: int var_1 = 0;, extern const int var_2 = 0; имеют внешнее связывание, верно?

Верно.

Оба объявления также являются определениями.

Сообщение от Captain Maxee

2. Если мы хотим получить доступ к определенным выше переменным в соседней единице трансляции, мы должны написать следующее: extern int var_1; extern const int var_2;, верно?

Да, верно.

Сообщение от Captain Maxee

3. Когда нам нужно определить переменную с внутренним связываем, мы поступаем так: static int var_3 = 0; ( в случае с обычной переменной ) и static const int var_4 = 0; ( в случае с константной переменной ), верно?

Да, верно.

Но в случае с const явно писать static не всегда обязательно. const переменная и так получит внутреннее связывание, если только она не объявлена как extern где-то в этой же единице трансляции.

Сообщение от Captain Maxee

Если определение static const int var = 0; эквивалентно определению const int var = 0; ( имеет внутреннее связывание по умолчанию ), то почему последнее ( const int var = 0; ) будет трактоваться как определение выше объявленной внешней extern const int var; ( если таковая имеется )?

Потому что совпадение имен (var в обоих случаях), говорит о том, что это - объявление одной и той же сущности, т.е. объявление одного и того же const объекта по имени var. Первое объявление явным образом назначило этому объекту внешнее связывание. После этого правило "внутреннее связывание по умолчанию" уже не применимо. Уже нет никакого "умолчания". Внешнее связывание было назначено явно.

Сообщение от Captain Maxee

Получается, const int var = 0; двусмысленно? Двусмысленно в том смысле, что когда выше есть объявление ( extern const int var; ) внешней константной переменной с таким же именем, const int var = 0; трактуется как определение этой переменной. Если же выше нет никаких объявлений внешних переменных, const int var = 0; трактуется как определение независимой переменной с внутренним связыванием? Вот именно этот момент мне непонятен.

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

C++
1
2
extern const int var;
const int var = 0;

и в этом

C++
1
2
const int var = 0;
extern const int var;

случае мы получаем const переменную с внешним связыванием. И только если переменная var в данной единице трансляции нигде явно не объявляется как extern, вступает в силу умолчательное правило - const переменная var получает внутреннее связывание.

@Mournful Max · 09.09.2017, 04:25 **[ТС]**

TheCalligrapher, спасибо. Теперь все понятно.

Добавлено через 2 минуты

Не по теме:

GbaLog-, hoggy, теперь я понял, о чем вы писали. Мне нужно было просто разжевать, я не понимал.

@hoggy · 09.09.2017, 20:09

Сообщение от TheCalligrapher

У числового литерала никакого адреса нет и быть не может.

хотите сказать, что данный код не корректен?

C++
1
2
3
const int& ref = 10;
const int* ptr = &ref;
std::cout << "address = " << ptr << std::endl;

Сообщение от УГнетатель

Как тут не вспомнить известную русскую пословицу про танцора, которому всё мешает?

действительно.
вы написали код, который содержит UB )))
и как тут теперь не вспомнить то про знаменитую пословицу?

Сообщение от УГнетатель

Да вроде как не содержит.

содержит ^^

теперь, немножко ловкости рук, и никакой фантастики:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#include <iostream>
 
template<class type>
const type* addr(const type& val)
{
    return &val;
}
 
int main()
{
    std::cout << *addr(10) << '\n';
    std::cout << *addr(11) << '\n';
    /*
    const int* addr_of_10 = addr(10);
    const int* addr_of_11 = addr(11);
    
    std::cout << *addr_of_10 << '\n';
    std::cout << *addr_of_11 << '\n';
    */
}

теперь поведение предсказуемое и не зависит от оптимизаций

в чем здесь подвох?
в строке:

C++
1
const int* addr_of_10 = addr(10);

указатель смотрел на труп.

@GbaLog- · 09.09.2017, 20:18

Сообщение от hoggy

хотите сказать, что данный код не корректен?

между вашим примером и &10 есть разница, как бы.

@TheCalligrapher · 09.09.2017, 20:26

Сообщение от hoggy

хотите сказать, что данный код не корректен?

C++
1
2
3
const int& ref = 10;
const int* ptr = &ref;
std::cout << "address = " << ptr << std::endl;

Данный код совершенно корректен. Но никакого отношения к взятию "адреса числового литерала" он не имеет. Строчка

C++
1
const int& ref = 10;

создает безымянный временный объект типа int, проинициализированный значением 10. Ссылка ref привязывается к этому временному объекту и вся дальнейшая работа ведется именно с этим временным объектом. Адрес, который вы печатаете - это адрес этого временного объекта.

Роль числового литерала 10 в этом коде заканчивается сразу после инициализации временного объекта. Все остальное, происходящее в этом коде к числовому литералу 10 никакого отношения не имеет.

@hoggy · 09.09.2017, 20:28

Сообщение от GbaLog-

между вашим примером и &10 есть разница, как бы.

конечно есть.
с точки зрения синтаксиса.
но не с точки зрения практического смысла.

рассмотрим ещё раз этот самый мой пример:

C++
1
2
3
const int& ref = 10;
const int* ptr = &ref;
std::cout << "address = " << ptr << std::endl;

теперь для вас будет сложный вопрос:
адрес какого объекта выводится в консоль?

если ниже вы допишите:

C++
1
std::cout << "value = " << *ptr << std::endl;

что за значение буде выведено в консоль?

ответьте себе на эти вопросы,
а затем заново внимательно прочитайте #23
который я написал специально для вас.

@TheCalligrapher · 09.09.2017, 20:33

Сообщение от TheCalligrapher

Роль числового литерала 10 в этом коде заканчивается сразу после инициализации временного объекта. Все остальное, происходящее в этом коде к числовому литералу 10 никакого отношения не имеет.

Другими словами, ваш код - это не более чем сокращенная форма записи для

C++
1
2
3
4
5
const int __internal_temp_var = 10;
const int &ref = __internal_temp_var;
const int *ptr = &ref;
...
// И т.д.

То есть никакого "адреса числового литерала" тут нет.

@hoggy · 09.09.2017, 20:35

Сообщение от TheCalligrapher

создает безымянный временный объект типа int, проинициализированный значением 10

другими словами мы получаем доступ к объекту числовой литерной константы.
у которого можно взять адрес.

а значит,

Сообщение от TheCalligrapher

Но никакого отношения к "адресу числового литерала" он не имеет.

имеет прямое отношение к "адресу числового литерала"

мы имеем полное право воспринимать циферки (числовые литеральные константы )
как полноценные prvalue объекты.

@GbaLog- · 09.09.2017, 20:38

hoggy, смотрите #40, #47.

@УГнетатель · 09.09.2017, 20:39

Сообщение от hoggy

содержит ^^

Тем, кого подводит память, напоминаю, что вопрос был про код в сообщении #35:

Сообщение от hoggy

хотите сказать, что код в #35 содержит UB?

Дублирую код из сообщения 35 здесь:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
#include <iostream>
 
template<class type>
const type* addr(const type& val)
{
    return &val;
}
 
int main()
{
    std::cout << addr(10) << '\n';
    std::cout << addr(11) << '\n';
}

Вы зачем-то подсунули вместо этого какой-то другой код.

Сообщение от hoggy

теперь поведение предсказуемое и не зависит от оптимизаций

Утверждение неверно, т.к. от оптимизаций зависит:
http://rextester.com/RJA75666 vc++, без оптимизаций
http://rextester.com/SNLFL9050 vc++, с оптимизациями
https://wandbox.org/permlink/ZDkg0jC8uRNrZyb1 g++, без
https://wandbox.org/permlink/fPiM0vyJanSZ4blm g++, с

Сообщение от hoggy

указатель смотрел на труп.

Рад, что вы хоть это понимаете.

@TheCalligrapher · 09.09.2017, 20:43

Сообщение от hoggy

другими словами мы получаем доступ к объекту числовой литерной константы.
у которого можно взять адрес.

Нет, мы получаем доступ к временному объекту, который не имеет вообще никакого отношения к "числовой литерной константе". Он лишь в момент своего рождения на один миг случайно "встретился" с этой константой - для инициализации - а после этого забыл о ее существовании навсегда и больше не имеет к ней никакого отношения.

@hoggy · 09.09.2017, 20:46

Сообщение от GbaLog-

смотрите #40, #47.

см #50

Сообщение от УГнетатель

Утверждение неверно, т.к. от оптимизаций зависит:

ну значит, компиляторы лажают.

@УГнетатель · 09.09.2017, 20:47

Сообщение от hoggy

ну значит, компиляторы лажают.

Я так не думаю.

@hoggy · 09.09.2017, 20:53

Сообщение от TheCalligrapher

Нет, мы получаем доступ к временному объекту, который не имеет вообще никакого отношения к "числовой литерной константе". Он лишь в момент своего рождения на один миг случайно "встретился" с этой константой - для инициализации - а после этого забыл о ее существовании навсегда и больше не имеет к ней никакого отношения.

и чем это с практической точки зрения отличается от:
"мы получаем доступ к временному объекту, который и есть объект числовой константы" ?

ничем.

приведите мне хотя бы один пример ситуации,
когда я не могу обращаться с числовыми литерными константами,
как с prvalue.

таких ситуаций нет.

Добавлено через 2 минуты

Сообщение от УГнетатель

Я так не думаю.

мне без разницы как вы думаете.
значение имеет стандарт языка.

либо код содержит UB,
либо лажают компиляторы.

@Mournful Max · 09.09.2017, 20:55 **[ТС]**

Не по теме:

Сообщение от hoggy

прочитайте #23

Сообщение от GbaLog-

смотрите #40, #47.

Сообщение от hoggy

см #50

* :D

@TheCalligrapher · 09.09.2017, 20:55

Сообщение от hoggy

мы имеем полное право воспринимать циферки (числовые литеральные константы )
как полноценные prvalue объекты.

В С++ нет понятия "prvalue объекта". Объект - это объект. Prvalue - это категория результата выражения.

Единственный контекст, в котором эти понятия встречаются, т.е. в котором prvalue связано с так называемым "result object" - это prvalue типа "класс" или "массив". Prvalue типа int ни с каким объектом не связано. Но даже в тех случаях, когда "result object" существует, этот объект - это не само prvalue, а отдельный самостоятельный объект, лишь инициализированный при помощи этого prvalue.

@DrOffset · 09.09.2017, 20:58

Не хочу ввязываться в эти бесполезные споры, только уточню насчет этого:

Сообщение от hoggy

ну значит, компиляторы лажают.

Не лажают. Согласно стандарту компилятор может переиспользовать память объекта после его смерти. Это совершенно легально - см. параграф 3.8 Object Lifetime. Поэтому то, что второй объект разместился в памяти первого после его смерти, нельзя назвать лажей компилятора.

@Mournful Max · 09.09.2017, 21:00 **[ТС]**

Не по теме:

Эти беседы напоминают спор про: "Стакан наполовину полон или наполовину пуст?" :stop:

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .

@Mournful Max Велосипедист... 353 / 220 / 73 Регистрация: 15.12.2015 Сообщений: 785
	09.09.2017, 04:25 [ТС]
	TheCalligrapher, спасибо. Теперь все понятно. Добавлено через 2 минуты Не по теме: GbaLog-, hoggy, теперь я понял, о чем вы писали. Мне нужно было просто разжевать, я не понимал. 0

@GbaLog- Любитель чаепитий 3745 / 1801 / 566 Регистрация: 24.08.2014 Сообщений: 6,020 Записей в блоге: 1
	09.09.2017, 20:38
	hoggy, смотрите #40, #47. 0

@Mournful Max
	09.09.2017, 21:00 [ТС]
	Не по теме: Эти беседы напоминают спор про: "Стакан наполовину полон или наполовину пуст?" :stop: 0

Раздельная компиляция. Связывание const-переменных

Решение