Было бы очень круто делать условную компиляцию на подобных ифах. Вместо возни с #ifdef

Кто-то из JetBrains хотел добавить аттрибуты. Это аналогичная идея, видимо.

Было бы очень круто делать условную компиляцию на подобных ифах. Вместо возни с #ifdef

http://blog.tartanllama.xyz/c++/2016/12/12/if-constexpr/ Можно, но только внутри методов.

http://blog.tartanllama.xyz/c++/2016/12/12/if-constexpr/ Можно, но только внутри методов.

Это понятно. Я про куски классов, как в примере выше.

Это понятно. Я про куски классов, как в примере выше.

Ага. Избавит от *_linux.hpp и *_win.hpp. Но это все мечты, т.к. это не просто фича языка, которые не особо просто в стандарт добавить, это еще поломает все компиляторы и код будет очень страшный и странный, когда уровень вложенности больше 1 будет.

Ага. Избавит от *_linux.hpp и *_win.hpp. Но это все мечты, т.к. это не просто фича языка, которые не особо просто в стандарт добавить, это еще поломает все компиляторы и код будет очень страшный и странный, когда уровень вложенности больше 1 будет.

Ну в D сделано, не так страшно. А может ошибаюсь.

Было бы очень круто делать условную компиляцию на подобных ифах. Вместо возни с #ifdef

А чем ifdef то не угодил

Нинраиццо посонам

А чем ifdef то не угодил

Ну, Страуструпу Си не угодил и появился C++. Надо как-то развиваться же.

Ну, Страуструпу Си не угодил и появился C++. Надо как-то развиваться же.

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

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

Это не только синтаксис.

Это не только синтаксис.

Ждем коммента

А чем ifdef то не угодил

1. Слабая читаемость 2. Сложные конструкции неудобно или невозможно реализовать 3. Препроцессор - зло 4. Не получится нормально оперировать типами

1. Слабая читаемость 2. Сложные конструкции неудобно или невозможно реализовать 3. Препроцессор - зло 4. Не получится нормально оперировать типами

1. Это ваше имхо, на мой взгляд как раз хорошая читаемость, которая подчеркивает опасность деяния. 2 Ну таки сложные да, а что там реализовать то не получилось? 3 Почему? 4 А зачем? И всегда можно const bool flag = true И компилятор все вырежет

На вкус и цвет. Я был бы рад жить в пещере и охотиться на мамонтов, но человек решил эволюционировать. Вам нравится ifdef, другим людям он не нравится и они хотят его эволюционировать.

На вкус и цвет. Я был бы рад жить в пещере и охотиться на мамонтов, но человек решил эволюционировать. Вам нравится ifdef, другим людям он не нравится и они хотят его эволюционировать.

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

Ну, auto добавили, std::array добавили, хотя потребности в них не было.

Добавили даже 1'000'000

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

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

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

Ну вот, scoped global constexpr if тоже теоретически чтение кода улучшит. И поддержку.

1. Это ваше имхо, на мой взгляд как раз хорошая читаемость, которая подчеркивает опасность деяния. 2 Ну таки сложные да, а что там реализовать то не получилось? 3 Почему? 4 А зачем? И всегда можно const bool flag = true И компилятор все вырежет

Нельзя в условной компиляции методов/полей класса использовать условия, зависящие от констант времени компиляции - трейтов, constexpr, типов и прочего. Это основная проблема

Ну вот, scoped global constexpr if тоже теоретически чтение кода улучшит. И поддержку.

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

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

Аргументы в продакшене возникают, а не на кухне, когда приходится это легаси поддерживать

Я не против ifdef. Он хорош для своих целей. Но добавить условную компиляцию в meta-часть нужно.

Аргументы в продакшене возникают, а не на кухне, когда приходится это легаси поддерживать

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

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

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

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

Обязательно плюсану

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

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

Вот синтаксис и обратную совместимость надо обдумывать

Нате за вас загуглил https://stdcpp.ru/

Потом киньте линк я яростно плюсану

Вот синтаксис и обратную совместимость надо обдумывать

Концепты же еще добавлять хотят, надо будет посмотреть, можно ли их тоже в scope завернуть.

Нате за вас загуглил https://stdcpp.ru/

я тут эту сслку устал постить. и в канале @ProCxxNews )))))

я тут эту сслку устал постить. и в канале @ProCxxNews )))))

Ну дак кого он ждет? Возникла знаковая идея пусть бежит постит. От того шо он в телеге поохает его хотелка в япе не появиться, а это рили вей. Если всем понравиться, они уж допрут до реализации не ломающей совместимость, ключевое слово в крайности добавят, не помрем

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

У меня есть глупый вопрос, который я в этом чате уже озвучивал, но раз снова речь про пропозалы зашла. Реален ли scoped enable_if? Т.е. есть n методов, у которых одинаковое условие в enable_if, можно ли добавить в язык scope для этих целей? В 17 стандарте constexpr if добавили, на базе которого можно было бы теоретически написать пропозал, но конструкция типа: template <typename T> class A { if constexpr (std::is_integral_v(T)) { void f1(); void f2(); } }; ломает язык. Собственно, есть ли шанс, что подобное кого-то заинтересует, если найдется не ломающее язык решение, и адекватна ли вообще идея?

Вообще, если такая конструкция возникает, то можно в сторону шаблонных Mixin-ов посмотреть

Но выглядит неплохим сахаром

Скоро C++ будет знать -1 человек

Скоро C++ будет знать -1 человек

std::numeric_limits<size_t>::max?

std::numeric_limits<size_t>::max?

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

std::numeric_limits<size_t>::max?

-1 == std::string::n_pos

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

Никто не знает C++, чего уж там

Никто не знает C++, чего уж там

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

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

тулы развиваются, язык упрощается

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

модули будут. Вон в вижле уже есть, и в шланге есть

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

А В СТАНДАРТЕ НЕТ

Но разная реализация и комитет упоролся какие добавлять

А В СТАНДАРТЕ НЕТ

а ты возьми и стандартизируй

Я на GCC

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

и я на gcc,причем на 4.6 :С

и я на gcc,причем на 4.6 :С

и вы просите модули, когда сидите на некрокомпилах?

я не прошу

ERROR: S client not available

Вот тока не начинай а

я и без них прекрасно себя чувствую)

если сильно повезет и мы взлетим на gcc по новее, то хотя бы 14е плюсы появятся

Да gcc топ компилятор. Ядро линя и почти весь открытый на нем вертят

топ, только при переезде он говорит что мы одно большое деприкейтед ;D

Да gcc топ компилятор. Ядро линя и почти весь открытый на нем вертят

а чем другие компиляторы не угодили?

ну шлангом по-моему ядро все еще не соберешь

ну шлангом по-моему ядро все еще не соберешь

смотря какое ядро ?

виндовса

если сильно повезет и мы взлетим на gcc по новее, то хотя бы 14е плюсы появятся

Эльбрус? :)

виндовса

ща git clone сделаю, и попробую сбилдить)

а чем другие компиляторы не угодили?

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

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

то есть clang не проверенный? Не, ну вы серьёзно, а?

а чем другие компиляторы не угодили?

Поддержка архитектур

Поддержка архитектур

Кстати тоже +1

ну шлангом по-моему ядро все еще не соберешь

ну потому что ядро и гцц сильно друг под друга заточены

Clang vs GCC (GNU Compiler Collection) Pro's of GCC vs clang: GCC supports languages that clang does not aim to, such as Java, Ada, FORTRAN, Go, etc. GCC supports more targets than LLVM. GCC supports many language extensions, some of which are not implemented by Clang. For instance, in C mode, GCC supports nested functions and has an extension allowing VLAs in structs. Pro's of clang vs GCC: The Clang ASTs and design are intended to be easily understandable by anyone who is familiar with the languages involved and who has a basic understanding of how a compiler works. GCC has a very old codebase which presents a steep learning curve to new developers. Clang is designed as an API from its inception, allowing it to be reused by source analysis tools, refactoring, IDEs (etc) as well as for code generation. GCC is built as a monolithic static compiler, which makes it extremely difficult to use as an API and integrate into other tools. Further, its historic design and current policy makes it difficult to decouple the front-end from the rest of the compiler. Various GCC design decisions make it very difficult to reuse: its build system is difficult to modify, you can't link multiple targets into one binary, you can't link multiple front-ends into one binary, it uses a custom garbage collector, uses global variables extensively, is not reentrant or multi-threadable, etc. Clang has none of these problems. Clang does not implicitly simplify code as it parses it like GCC does. Doing so causes many problems for source analysis tools: as one simple example, if you write "x-x" in your source code, the GCC AST will contain "0", with no mention of 'x'. This is extremely bad for a refactoring tool that wants to rename 'x'. Clang can serialize its AST out to disk and read it back into another program, which is useful for whole program analysis. GCC does not have this. GCC's PCH mechanism (which is just a dump of the compiler memory image) is related, but is architecturally only able to read the dump back into the exact same executable as the one that produced it (it is not a structured format). Clang is much faster and uses far less memory than GCC. Clang has been designed from the start to provide extremely clear and concise diagnostics (error and warning messages), and includes support for expressive diagnostics. Modern versions of GCC have made significant advances in this area, incorporating various Clang features such as preserving typedefs in diagnostics and showing macro expansions, but GCC is still catching up. GCC is licensed under the GPL license. clang uses a BSD license, which allows it to be embedded in software that is not GPL-licensed. Clang inherits a number of features from its use of LLVM as a backend, including support for a bytecode representation for intermediate code, pluggable optimizers, link-time optimization support, Just-In-Time compilation, ability to link in multiple code generators, etc. Clang's support for C++ is more compliant than GCC's in many ways. Clang supports many language extensions, some of which are not implemented by GCC. For instance, Clang provides attributes for checking thread safety and extended vector types.

https://clang.llvm.org/comparison.html#gcc

так проще

Это все слова, ты нечего не сможешь написать кроме них. Ну и Java не язык. А так, всегда защитники одной вещи могут найти 10 серьезных аргументов в пользу за или против, то же справедливо и наоборот.

GCC только Java 1.* полностью поддерживал. В 7.1 версии выпилили и эту поддержку.

1.2 вроде, лол

И правильно, не нужна богомерзкая жаба

Это все слова, ты нечего не сможешь написать кроме них. Ну и Java не язык. А так, всегда защитники одной вещи могут найти 10 серьезных аргументов в пользу за или против, то же справедливо и наоборот.

Что занчит я что-то защищащю? я просто показываю, что на одном gcc мир не сошёлся

И правильно, не нужна богомерзкая жаба

ага, ну да, конечно.

Что занчит я что-то защищащю? я просто показываю, что на одном gcc мир не сошёлся

Ну таки да, GCC есть врожденные болячки. Но вот лечить их вряд ли будут, кодовая база слишком большая.

Ну таки да, GCC есть врожденные болячки. Но вот лечить их вряд ли будут, кодовая база слишком большая.

Если болячки не лечат, то плохо это