Чуваки а можно как нибудь внутри cmake проверить, что поддерживается тот или иной стандарт? Мне нужно выключить сборку одного из проектов если не поддерживается c++14

CMAKE_CXX_STANDARD (емнип)

Есть ли среди вас сторонники такого кодинг-стайла, в котором именование членов класса начинается с префикса "m_"? Если вы используете такой префикс, то какие плюсы находите? Я читал, что так проще с автозаполнением - IDE подскажет по "m_" доступные члены. А с постфиксом "_" менее удобно в плане подсказок.

Участвую во втором проекте подряд с именованием m_ Можно именовать с m_ поля классов, а с g_ глобальные переменные, тогда по префиксу сразу понятно шо цэ такэ - в этом мне видится преимущество над просто _

Участвую во втором проекте подряд с именованием m_ Можно именовать с m_ поля классов, а с g_ глобальные переменные, тогда по префиксу сразу понятно шо цэ такэ - в этом мне видится преимущество над просто _

я тоже "точкой" g_ пользуюсь :)

Ну, 'm_' вообще-то значит mutable

c_ - const

я тоже "точкой" g_ пользуюсь :)

ну g_ конечно отношения к подсказкам по точке не имеет отношения

Ну, 'm_' вообще-то значит mutable

member?

s_ - static

Ну, 'm_' вообще-то значит mutable

эээ

Ну, 'm_' вообще-то значит mutable

О_о весело у вас

Участвую во втором проекте подряд с именованием m_ Можно именовать с m_ поля классов, а с g_ глобальные переменные, тогда по префиксу сразу понятно шо цэ такэ - в этом мне видится преимущество над просто _

Главное в венгерку не трансформировать

мне кажется, что const/mutable - это уже детализация. так можно докатиться до указания типа переменной в имени

lpctstrFirstName

CMAKE_CXX_STANDARD (емнип)

А как его готовить именно для того кейса, что я описал? Насколько я знаю, эта штука просто подпихивает компилятору флаг -std=c++{N}, а в случае с msvc вообще ничего не делает вроде (возможно, в msvs 2017 что-то изменилось)

Главное в венгерку не трансформировать

хы, у нас и так она такая

дык он ж проверяет фичи компилятора, если нету, то он ругнется чем-то типа "Compiler %s is not able to build a simple program". Вот только как готовить я ща не вспомню, голова не варит совсем

ну типо g_globalVariableName

m_classMember

CXX_STANDARD — CMake 3.1.3 Documentation cmake.org set_property(TARGET tgt PROPERTY CXX_STANDARD 11). This property is initialized by the value of the CMAKE_CXX_STANDARD variable if it is set when a target is created.

Чуваки а можно как нибудь внутри cmake проверить, что поддерживается тот или иной стандарт? Мне нужно выключить сборку одного из проектов если не поддерживается c++14

auto autoFileName = ... ))

дык он ж проверяет фичи компилятора, если нету, то он ругнется чем-то типа "Compiler %s is not able to build a simple program". Вот только как готовить я ща не вспомню, голова не варит совсем

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

венгерка это дно...

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

чуть выше предложили возможное решение

сча пробну

include(CheckCXXCompilerFlag) CHECK_CXX_COMPILER_FLAG("-std=c++14" COMPILER_SUPPORTS_CXX14) if(COMPILER_SUPPORTS_CXX14) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++14") message(STATUS "The compiler ${CMAKE_CXX_COMPILER} has C++14 support!") else() message(FATAL_ERROR "The compiler ${CMAKE_CXX_COMPILER} has no C++14 support. Please use a different C++ compiler.") endif()

еще CMAKE_CXX_KNOWN_FEATURES можно попробовать, но там фичи отдельно

хотя, с какой-то версии смейка есть прям фича cxx_std_14

Парни! Вот вы там все, корутины, смартпойнтеры, интрузив поинтеры, концепты... А в жизни-то всё проще, вы бы знали как я "люблю" такой вот код: if(rc == S_DB_NO_DATA) { // <<ATTENTION>> *** ver 3.0 *** // next line has been removed //data->Free(); return false; } else { return true; }

согласен, ужжасное смещение и переносы скобочек и пробела после ифа нет)

согласен, ужжасное смещение и переносы скобочек и пробела после ифа нет)

Смещение вставилось при вставке сюда. Не в нём дело.

Чем проще, тем лучще

Главное до индусского кода не доводить

Главное до индусского кода не доводить

Т.е. это вам не индусский код? Нуну...

else if нет

Всё ок

else if (rc != S_DB_NO_DATA)

return true; // OK

// returns true if rc isn't S_DB_NO_DATA

return true; // OK

return (bool) RESULT_OK; // RESULT_OK - constant for more readabilier code

Выход из функции в елсе для читаемости..

Так все делают

Парни шалом всем!

хеллоу

return (bool) RESULT_OK; // RESULT_OK - constant for more readabilier code

во, чисто по-индусски, и топ инглиш

двойная сравнительная степень в каментах

C-style cast

most

индусский код это когда if (to_string(var).size() == 5) ))

ибо size "true" = 4 а "false" = 5

ибо size "true" = 4 а "false" = 5

а как to_string работает? По моему даже boost::lexical_cast<std::string>(bool) даст 0 или 1

Так все делают

Упаси госспади делать такое вместо "return rc != S_DB_NO_DATA;"

а как to_string работает? По моему даже boost::lexical_cast<std::string>(bool) даст 0 или 1

ну в классичской шутке про индусский код было именно так. там правда java была

Упаси госспади делать такое вместо "return rc != S_DB_NO_DATA;"

там же была очистка ресурсов до этого, да и далеко не самое страшное, что можно увидеть. Практически стилистистический момент.

CXX_STANDARD — CMake 3.1.3 Documentation cmake.org set_property(TARGET tgt PROPERTY CXX_STANDARD 11). This property is initialized by the value of the CMAKE_CXX_STANDARD variable if it is set when a target is created.

Похоже что (по крайней мере для студии) это не работает

там же была очистка ресурсов до этого, да и далеко не самое страшное, что можно увидеть. Практически стилистистический момент.

Категорически не согласен. 1. Когда — "до этого"? В начале времён? Мусор нужно выкидывать. Мусор ухудшает читаемость и повышает когнитивную нагрузку. 2. Добавление вложенности, когда логически этой вложенности нет, делает то же самое. 3. Не худшее. Но "не худшее" - это не то чтобы плюс.

Категорически не согласен. 1. Когда — "до этого"? В начале времён? Мусор нужно выкидывать. Мусор ухудшает читаемость и повышает когнитивную нагрузку. 2. Добавление вложенности, когда логически этой вложенности нет, делает то же самое. 3. Не худшее. Но "не худшее" - это не то чтобы плюс.

В ревью я это бы ни за что не одобрил.

@pr_honey

Thx!!

Категорически не согласен. 1. Когда — "до этого"? В начале времён? Мусор нужно выкидывать. Мусор ухудшает читаемость и повышает когнитивную нагрузку. 2. Добавление вложенности, когда логически этой вложенности нет, делает то же самое. 3. Не худшее. Но "не худшее" - это не то чтобы плюс.

А еще лишнее отрицание ухудшает читаемость, например. Такие выражения потом могут заканчиватся каким-нибудь return !(!(a != !b) && !(b || !c)).

Это еще что, я тут в одной книжке прочитал, что if (a) x = f(); else if (b) y = f(); else z = f(); Это не торт, и нужно (a?x:(b?y:z)) = f();!

А еще лишнее отрицание ухудшает читаемость, например. Такие выражения потом могут заканчиватся каким-нибудь return !(!(a != !b) && !(b || !c)).

Согласен. Но здесь из контекста непонятно, насколько оно лишнее. Даже названия метода нет. Может это отрицание и правда лучше оставить здесь, а не прокидывать по всему коду.

Это еще что, я тут в одной книжке прочитал, что if (a) x = f(); else if (b) y = f(); else z = f(); Это не торт, и нужно (a?x:(b?y:z)) = f();!

от автора Перла?

Это еще что, я тут в одной книжке прочитал, что if (a) x = f(); else if (b) y = f(); else z = f(); Это не торт, и нужно (a?x:(b?y:z)) = f();!

Я такого знаю ИРЛ.

Хз, "тонкости с++" или както так называлась

Парни! Вот вы там все, корутины, смартпойнтеры, интрузив поинтеры, концепты... А в жизни-то всё проще, вы бы знали как я "люблю" такой вот код: if(rc == S_DB_NO_DATA) { // <<ATTENTION>> *** ver 3.0 *** // next line has been removed //data->Free(); return false; } else { return true; }

в VS 15.8 есть рефактор ,который автоматом такие штуки правит

Похоже что (по крайней мере для студии) это не работает

да, там через круп. вроде в смаке 3.11 фиксед было

в VS 15.8 есть рефактор ,который автоматом такие штуки правит

да и clang-format тоже умеет.

Есть ли среди вас сторонники такого кодинг-стайла, в котором именование членов класса начинается с префикса "m_"? Если вы используете такой префикс, то какие плюсы находите? Я читал, что так проще с автозаполнением - IDE подскажет по "m_" доступные члены. А с постфиксом "_" менее удобно в плане подсказок.

вот кстати сразу всплыл вопрос в голове, а насколько хорош/плох кодинг стайл с приписыванием this-> всегда и везде

(но вообще я прочитал до конца тот кусок кода ,и понял, что его надо зарефактить до return rc != S_DB_NO_DATA; сначала я подумал про инверсию ифа)

вот кстати сразу всплыл вопрос в голове, а насколько хорош/плох кодинг стайл с приписыванием this-> всегда и везде

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

да, там через круп. вроде в смаке 3.11 фиксед было

:( у нас нельзя cmake 3.11 - он нинзю не находит почему то

странно... надо им баг закинуть

ну просто как альтернатива, по идее вместо g_ для глобальных можно всегда дописывать ::, а для мемберов вместо m_ дописывать this->, просто не понимаю в чём их принципиальное отличие при написании кода

Упаси госспади делать такое вместо "return rc != S_DB_NO_DATA;"

Спасибо, Макс, ты оживил во мне веру в человечество...

ну просто как альтернатива, по идее вместо g_ для глобальных можно всегда дописывать ::, а для мемберов вместо m_ дописывать this->, просто не понимаю в чём их принципиальное отличие при написании кода

можно так, да. отличия тащемта, кроме шаблонной поебени, чисто косметические. Ну, и еще с :: эта поебень, про которую @webreh говорит с тем, как сработают customization points

странно... надо им баг закинуть

возможно там поменяли механизм поиска или чё то такое, но раньше (в 3.8 ещё точно робит) достаточно было закинуть каталог нинзи в PATH и всё находилось, в 3.11 перестало

там же была очистка ресурсов до этого, да и далеко не самое страшное, что можно увидеть. Практически стилистистический момент.

Стилистический момент? ДА БЛИН ХРЕН! Там весь код в таких стилистических моментах! Итого, вместо того, чтобы иметь 2k чистого и продуктивного кода, там блиа всё в этих IFах которые не делают нихрена!

Категорически не согласен. 1. Когда — "до этого"? В начале времён? Мусор нужно выкидывать. Мусор ухудшает читаемость и повышает когнитивную нагрузку. 2. Добавление вложенности, когда логически этой вложенности нет, делает то же самое. 3. Не худшее. Но "не худшее" - это не то чтобы плюс.

Макс, ты лучший!

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

Стилистический момент? ДА БЛИН ХРЕН! Там весь код в таких стилистических моментах! Итого, вместо того, чтобы иметь 2k чистого и продуктивного кода, там блиа всё в этих IFах которые не делают нихрена!

вспомнил один кек, когда у меня юзался композитный листнер, а потом я зарефактил один его вложенный листнер, и забыл удолить этот композитный листнер. @fvnever помнит эту историю, лол Там была составная шняга из листнеров-примитивов, но в итоге один стал общим, и можно стало дропнуть композитный листнер

вот кстати сразу всплыл вопрос в голове, а насколько хорош/плох кодинг стайл с приписыванием this-> всегда и везде

Ну если это реально надо, то нормально. А так -- если тебя не заманает всё время читать этот лишний this-> -- ну, тогда наслаждайся, чо...

вспомнил один кек, когда у меня юзался композитный листнер, а потом я зарефактил один его вложенный листнер, и забыл удолить этот композитный листнер. @fvnever помнит эту историю, лол Там была составная шняга из листнеров-примитивов, но в итоге один стал общим, и можно стало дропнуть композитный листнер

ЯНХНП, если чё...

ЯНХНП, если чё...

да, там сложно без кода, а на рабочий код за примером лень лезть

ну просто как альтернатива, по идее вместо g_ для глобальных можно всегда дописывать ::, а для мемберов вместо m_ дописывать this->, просто не понимаю в чём их принципиальное отличие при написании кода

Не путай всё в одну кашу. g_ и :: -- совсем не одно и то же.

Не путай всё в одну кашу. g_ и :: -- совсем не одно и то же.

@AlexFails уже сказал про это

надо бы эту штуку формализовать до строчки в FAQ с примерчиком

Макс, ты лучший!

???

Может кто подскажет. Хочу в eclipse подебажить проект который собирается с помощью makefiles. Собрал проект в дебаг моде, запускаю на дебаг в eclipse но он не может найти исходники, из-за чего можно только дизассемблить. В чем может быть трабл? С Eclipse никогда до этого не работал...

Может кто подскажет. Хочу в eclipse подебажить проект который собирается с помощью makefiles. Собрал проект в дебаг моде, запускаю на дебаг в eclipse но он не может найти исходники, из-за чего можно только дизассемблить. В чем может быть трабл? С Eclipse никогда до этого не работал...

@crackedmind пиу

Может кто подскажет. Хочу в eclipse подебажить проект который собирается с помощью makefiles. Собрал проект в дебаг моде, запускаю на дебаг в eclipse но он не может найти исходники, из-за чего можно только дизассемблить. В чем может быть трабл? С Eclipse никогда до этого не работал...

сегодня @crackedmind в топе, он подскажет :)

Оук, спасиб

Может кто подскажет. Хочу в eclipse подебажить проект который собирается с помощью makefiles. Собрал проект в дебаг моде, запускаю на дебаг в eclipse но он не может найти исходники, из-за чего можно только дизассемблить. В чем может быть трабл? С Eclipse никогда до этого не работал...

Ты не собрал с отладочной информацией.