в любом случае нужно забить

мне вот говорят, что это ill-formed

кто конкретно

[](){} объект - функтор неизвестного типа

все

ну наличие ODR violation делает программу ill-formed

скомпиль другим компилятором

или обращения к классу, забыл

скомпиль другим компилятором

шутишь?

или ты про пример

почему?

почему это бага анализатора? хз, поскольку здесь нет нарушения ODR

или ты про пример

про пример

почему это бага анализатора? хз, поскольку здесь нет нарушения ODR

я категорически не уверен, что линкер может ошибиться в определении ODR violation

я категорически не уверен, что линкер может ошибиться в определении ODR violation

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

я такого пункта найти не могу

может Антон поможет

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

я, к сожалению, не знаю весь стандарт

@antoshkka

и у меня нет ни малейшей идеи, как это гуглить

да здесь не гуглить, здесь штудировать стандарт надо

Завтра начинается МИНИ ревью новой сортировки в Boost.Sort : pdqsort

The (mini) review for pdqsort will start tomorrow 6/21, and run through 6/30. I will manage the review; Orson Peters is the author. The proposed boost source is here: https://gist.github.com/orlp/24f27aada1ed724d1809b372c33eb92e Documentation is here: https://github.com/orlp/pdqsort#pdqsort And a draft paper is here: https://drive.google.com/open?id=0B1-vl-dPgKm_T0Fxeno1a0lGT0E If you're interested, please answer these questions: 1. Are there any specific concerns you have about pdqsort vs. std::sort? 2. Does it compile for you when you try to use it as a replacement for std::sort? 3. How does the performance compare on your system vs. std::sort? 4. Do you think we should include pdqsort in Boost.Sort? 5. Do you have any concerns about switching the default/fallback sort in Boost libraries (including Boost.Sort) from std::sort to pdqsort?

кто хочет помочь, что сделайте ревью, плиз и зашлите результат в boost mailing list

линкер утверждает, что вот эта строка модифицирует определение типа Around::SomeStruct Around::SomeStruct::SomeStruct() : b([]() {})

реализация конструктора в данном случае не является часть определения класса, это отдельно вынесенная реализация конструктора класса, на которую накладывается свое правило ODR

А что у нас, cmake не умеет precompiled headers?

не могу найти как выставить

Через жопу умеет.

Оно ж копилезависимое.

мда

Советую опробовать вот это: https://github.com/sakra/cotire

Оно там обмазано и включеня все эти PH.

ну что сказать, я удивлен конечно

А что у нас, cmake не умеет precompiled headers?

stdafx.cpp должен быть помечен как создающий pch set_source_files_properties(stdafx.cpp PROPERTIES COMPILE_FLAGS "/Yc\"${THIS_LIB_PCH}\"" ) а все исходные файлы, что используют pch должны его включить set_source_files_properties(${source} PROPERTIES COMPILE_FLAGS "/Yu\"${THIS_LIB_PCH}\"" )

вместо ${THIS_LIB_PCH} имя твоего проекта

Да, спасибо

выглядит как костыль конечно и нужно будет переделывать cmake проект

так что пока забью :)

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

rolis_library( smartcard COMPILE_FLAGS -D_AFXDLL -D_MBCS -DROLIS_SMARTCARD_EXPORTS SOURCES ${rolis_SOURCE_DIR}/rolis/SmartCard.h SmartCard.cpp StdAfx.h PCH StdAfx.h PCH_SOURCE StdAfx.cpp DEPENDS subclass LINK_LIBS winscard rpcrt4 MFC )

ну а уже в макросе обрабатываем как нам требуется PCH

rolis_library( smartcard COMPILE_FLAGS -D_AFXDLL -D_MBCS -DROLIS_SMARTCARD_EXPORTS SOURCES ${rolis_SOURCE_DIR}/rolis/SmartCard.h SmartCard.cpp StdAfx.h PCH StdAfx.h PCH_SOURCE StdAfx.cpp DEPENDS subclass LINK_LIBS winscard rpcrt4 MFC )

Такс, можно подробнее? :)

Т.е. вы создали PCH команду?

и PCH_SOURCE

нет, написали макрос который внутри делает всю грязную работу

теже set_source_files_properties только внутри макроса

А можно взять cotire)

наверняка cotire это делает лучше, поскольку поддерживает все современные компиляторы

Да, потому и советую.

я хотел лишь показать, что ничего под катом волшебного нет

Справедливо!

Нарушает ли лямбда, объявленная в inline шаблонной функции и замыкающая ее параметры, правило ODR?

template <typename T> inline std::function<void()> f(T* object) { return [object](){}; }

да как лямбда может нарушать ODR?

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

А что у нас, cmake не умеет precompiled headers?

умеет, гугли cotire

A type defined within the body of an extern inline function is the same type in every translation unit.

stdafx.cpp должен быть помечен как создающий pch set_source_files_properties(stdafx.cpp PROPERTIES COMPILE_FLAGS "/Yc\"${THIS_LIB_PCH}\"" ) а все исходные файлы, что используют pch должны его включить set_source_files_properties(${source} PROPERTIES COMPILE_FLAGS "/Yu\"${THIS_LIB_PCH}\"" )

все это платформозависимая хуета и не нужно

ну значит он один

(у тебя там шаблон, если ты об этом, для каждого инстанса шаблона будет свой тип лямбды)

так что пока забью :)

cotire ставится с полпинка и работает со всеми компиляторами

cotire ставится с полпинка и работает со всеми компиляторами

ну может быть попробую

ну может быть попробую

если будут вопросы - задавай, я у себя использую

(у тебя там шаблон, если ты об этом, для каждого инстанса шаблона будет свой тип лямбды)

это гарантируется стандартом?

конечно, да

хотя, не понятно откуда вопрос. [](){} - это лямбда выражение, как если бы ты написал 1+1

что здесь definition?

ERROR: S client not available

это лямбда-выражение является объектом некоторого типа

и?

1+1 тоже выражение некоторого типа

An inline function shall be defined in every translation unit in which it is odr-used and shall have exactly the same definition in every case

и?

ну тут на самом деле есть дефинишн

у тебя блин шаблон

An inline function shall be defined in every translation unit in which it is odr-used and shall have exactly the same definition in every case

если у тебя одно определение, то?

втопку инлайн

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

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

нафига

по определению инстанцирования шаблона

это не функция

это шаблон функции

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

после чего не заявить, что в разных модулях компиляции это имя генерируется по-разному

поэтому реализация функции нарушает правило ODR

потому что тело инстанцированного шаблона фукнции гарантирует уникальность определенных в нем типов, если бы они были

уникальности недостаточно

все что справедливо для класса/функции, будет справедливо и для инстанцированных шаблонов класса/функции

нужно еще единообразие между модулями компиляции

нужно еще единообразие между модулями компиляции

это с чего

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

потому что в противном случае заданная шаблонная функция ill-formed, поскольку в разных модулях компиляции будет сгенерирована разная ее реализация

это будут разные шаблонные функции

потому что в противном случае заданная шаблонная функция ill-formed, поскольку в разных модулях компиляции будет сгенерирована разная ее реализация

если бы они были по разному определены

но нет, они везде одни и теже

поэтому ODR не нарушается

и я тут перепроверил, компилятор MSC 14 уверен, что этот код нарушает ODR

это будут разные шаблонные функции

, с одинаковыми сигнатурами, и это было бы ill-formed, разве нет?

и я тут перепроверил, компилятор MSC 14 уверен, что этот код нарушает ODR

msvc вообще не очень хорошо с++ умеет, так что делай скидку

, с одинаковыми сигнатурами, и это было бы ill-formed, разве нет?

для шаблонов не требуется, компилятор выбросит лишние инстансы и оставит один

для шаблонов не требуется, компилятор выбросит лишние инстансы и оставит один

йеп