Здравствуйте.

Имеется такой код:

А теперь самое интересное:
в gcc 4.1.2 это не линкуется - http://codepad.org/LB1506hR
в gcc 4.3.2 линкуется - http://ideone.com/q1Uik8
в gcc 4.5.2 опять не линкуется - это уже на моей машине. ссылку дать не могу.
в gcc 4.7.2 снова линкуется - http://ideone.com/rP6zIF

Вопрос:
ошибка у меня и необходимо добавить

или ошибка в компиляторах, в которых не линкуется ?
И вообще, что за чехарда с компиляторами (вернее с версиями) ? Или м.б. это какая-то настройка (на ideoone она включена, а у меня и на codepad нет) ? Если да, то какая ?

Спасибо.

Вы уверены в версии? (возможно еще разные версии выходили параллельно (?не знаю), то есть возможно еще год релиза нужно смотреть)

В шестой студии тоже нельзя было инициализировать стат.константы в классе.
В поздних версиях уже можно.

Почему?
Видимо в силу тумнности выражений стандарта С++, создатели компиляторов не вкурили его достаточно глубоко.   
Посему старые версии такое не переваривают.

Новые же версии, (даже с ключами например -std=c++98), переваривают нормально.

> Вы уверены в версии? 
Да, вроде. Вызывал g++ -v и он выдал 4.5.2. По поводу года не скажу. Он был в поставке с Ubuntu 11.04.
Интересно то, что ошибка линковки возникает только если брать адрес (сылку) этой переменной (в моём случае это std::min). Если же использовать только как rvalue, то ошибки нет.
Я, всё-таки, склоняюсь к мнению, что тут дело в настройках компилятора...

А..., так это не из той оперы...

Это просто оптимизация.
Если убрать оптимизацию, то и новые gcc не будут компилить.
оптимизация: -O*

Вы не привели комм строку.
В общем добавьте туда (в комм строку) одно из:

Скорей всего поможет... (Комилятор все-же не из прошлого века).

borisbn, Да я понимаю ваше молчание...
Действительно, с какого это перепуга, правильность кода (компилируемость) зависит от введения/невведения оптимизации.
Код либо правильный, либо нет. Оптимизация на это не должна никак влиять.

Очень похоже на баг gcc. (Хотя логически понять причины такого поведения можно)
Вот максимально-сокращенный код который не компилируецца у меня на gcc 4.7.0 ни при каких оптимизациях.
Но кстати, прекрасно компилицца на студии.


Приглашаюцца к обуждению опытные gcc-шники, зубры-линуксоиды, а также вообще знатоки приплюснутых стандартов.
Велкам...

volatile, не.. я не по этому молчал. Вы попросили посмотреть параметры компиляции на моей машине, а её у меня на время забрали.
А по поводу оптимизации - вроде в online-компиляторах она выключена... И да.. не должна она влиять. Единственное - м.б. есть какая-то опция, влияющая на такое поведение ?


Поддерживаю. Ждёмс.

  , может все таки у студии баг (именнуемый в народе фичей) ?  




Это сообщение отредактировал(а) mes - 9.6.2013, 12:49

mes,  ваша цитата мимо кассы.  здесь говорицца для случая когда нет инициализации в описании класса. 
(Кстати в этом случае и студия компилировать не будет)
И потом, давайте оставим студию, раз вас так она раздражает.

Сам факт что компилируемость кода зависит от оптимизации, уже достаточно стрёмен, не находите ? 



Это сообщение отредактировал(а) volatile - 9.6.2013, 23:26

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


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



ни капли не раздражает, просто у них свой взгляд на вещи и ориентироваться по ней на стандартность поведения "рискованно"   

Это сообщение отредактировал(а) mes - 13.6.2013, 19:48

ну слава богу   

остальное весьма спорно.


Это сообщение отредактировал(а) volatile - 13.6.2013, 23:25

 
Да и кстати, в окончательном варианте стандарта 2011, вашей цитаты, вообще нет (по крайне мере в данном пункте, и ближайших окрестностях).   


Дальше идёт про другое...

Так что спорить о переводе не известно откуда взятой фразы, не имеет смысла.

Добавлено @ 00:27


Это сообщение отредактировал(а) volatile - 14.6.2013, 00:38

ну так с более 10ка лет был актуален другой стандарт, в котором эта фраза была актуальна..   



ну и ?? обратили внимание на constexpr specifier ? и гдепродолжение цитаты, которое описывает приведенный Вами случай ? пару строчек ниже :


Добавлено @ 01:02

если внимательно прочитали цитату, то

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

Это сообщение отредактировал(а) mes - 14.6.2013, 01:04

mes, Ну хорошо, давайте предположим на миг что ваша трактовка верна, 
В вашей цитате ведь говорицца вообще о "статической константе" как таковой.
Там нет ни слова ни о взятии адреса, ни о чем либо подобном.
Что означает (если трактовать по вашему), абсолютно правильный компилятор вообще не должен принимать 
статическую константу, без отдельного определения ее где-то в *.cpp
Не только взятие адреса (о котором, повторяю нет ни слова), но и именно саму константу!
Именно так ваша трактовка и звучит. Не больше и не меньше.
Но gcc, вашей трактовке не соответствует, даже с ключом -pedantic. (тестовый код элементарен, не привожу)
Более того, вашей трактовке, не соответствует ни один известный мне компилятор.   
Так что смысла продолжать дисскуссию не вижу.

давайте хоть на миг )


не совсем, в середине цитате говорится еще об использовании константного выражения ассоциированного с константой   



нет, Вы не правильно трактуете мою трактовку.. так упустили то самое предложение из середины цитаты.. и не обратили почему же стоит "still" и "if" в последнем предложении, которые явно намекают, что должна быть еще одна ситуация..


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


именно так Вы хотите ее воспринимать.. 


не моей ))


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

Намекают - сильно сказано!   
Не сомневаюсь что с вашей выдающейся способностью к софистике и из туманных намеков в купе с "still" и "if" можно вывести все что угодно...


Это сообщение отредактировал(а) volatile - 16.6.2013, 00:03

иногда достаточно  просто перечитать заново и вникнуть в пропущенное при первом чтении  

Добавлено через 2 минуты и 58 секунд
ладно, чтоб не уходить в переспоривание озвучу свою трактовку с коментариями..

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

В этом случае константа не участвует в процессе, она лишь служит переносчиком константного выражения.. 

Теперь подойдем к классу и нашей цитате.. 

ну тут понятно без пояснений

ее объявление (именно объявление, не определение) может быть специфицировано констным выражением. "Объявление" нам говорит, что объект (в памяти) не определен.

В этом случае дата-член может появляться в константном выражении.. Как раз об этом говорилось в начале поста..Не забывайте, что объект  (lvalue в терминах c++)  пока не определен.

дата-член должен быть к тому же определен вне класса, если используется в программе.
Вот тут наконец то определяем сам объект.. И обратите внимание в первом случае было "появляeтся" (can appeаr), а теперь "используется" (used), потому как в первом случае у нас имелась  только декларация, и использования объекта не было..


ну тут опять без фокусов, если указали инициализатор при декларации в классе, то при определении вне класса он должен отсутствовать..

Ну вроде и все..

Это сообщение отредактировал(а) mes - 16.6.2013, 10:58

Да можно хоть сто раз перечитывать. Нет там ничего.

mes,  вашу точку зрения я понял. спасибо.



Это сообщение отредактировал(а) volatile - 16.6.2013, 09:24

Мес, не обижайтесь, не стоило здесь приводить это все. (хотя еще раз спасибо).
Да я прекрасно понял что вы хотите сказать.
Я и без того, разделяю ваше мнение насчет подстановки констант. 
Еще в начале:

Беда только в том что все это являецца лишь логическим выводом.
И бездоказательно, к сожалению.

Bjarne Stroustrup - ему можно верить ? 
The C++ Programming Language (Third Edition)


Добавлено @ 13:09
в его ж d&e тоже вроде было на эту тему.. 


хотя да, опять догадки.. никаких выводов   

Это сообщение отредактировал(а) mes - 16.6.2013, 16:16

borisbn, насколько удалось выяснить в codepad.org например, она включена.

Почему в таком случае, он выдает ошибку, (а 4.7.0 абсолютно при тех-же ключах не выдает) остаецца только гадать...

Впрочем не сомневаюсь что mes, опираясь на пару, тройку "still" и "if" в стандарте,
выведет "основательное доказательство" и этому факту.
 


Это сообщение отредактировал(а) volatile - 16.6.2013, 23:54

Так тут дело не в mes`е.. а в самом стандарте, который описан в стиле "всегда так, кроме, когда это не так"   

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

И так:
Рассмотрим некий абстрактный идеальный случай:
одна машина, одна операционка, одинаковое окружение, одни и теже библиотеки и т.д. и т.д. 
один С++ код, без "undefined behavior" и "implementation defined"
И есть два разных, строго_соответствующих_стандарту С++ компилятора. (само собой без багов)

Утверждение: Удачная компиляция+сборка на одном компиляторе
не дает никаких гарантий, что на другом компиляторе
этот же код будет компилироваться+собираться.

Вопрос: Справедливо ли по вашему это утверждение?
пожалуйста, ДА или НЕТ ?

(Без каких-то дополнительных условий.
Вопрос звучит так, как он звучит.)

Добавлено через 34 секунды
Или может голосование устрить?    
но прежде всего, я хотел бы услышать ваше мнение.

да, если код  ill-formed  при этом ill-formed код может компилироваться и работать вполне нормально, а может и нет.. 
нет, если код well-formed и компиляторы соответствуют стандарту.. 

да + нет ->  ДА 


Это сообщение отредактировал(а) mes - 23.6.2013, 21:15

volatile, я тут на досуге почесал репу,  и понял  что вам  мешает воспринимать мои доводы  



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

но в итоге:
 только well-formed код с одной стороны, и соответствующий этим правилам (не обязательно основному стандарту) компилятор с другой стороны могут гарантировать успешность предприятия   

Это сообщение отредактировал(а) mes - 27.6.2013, 21:03