Вот вроде бы все так безобидно начиналось — макросы. Ну это же, можно сказать, почти тупая замена текста. Ну ОК, добавили параметры макроса, это чуть более сложная замена текста.
А сейчас что? Шаблоны, constexpr и иже с ними — это фактически урезанный C++ поверх C++
Но, простите, как это отлаживать? Если обычный С++ можно в дебагере пройтись по шагам и все станет ясно — то тут мы просто имеем ошибку без всякой возможности понять причину ее возникновения (окромя как догадаться).
Вот, для примера:
template <class T1>
struct TestStruct1
{
constexpr TestStruct1()
{
constexpr int a = sizeof(T1) + 1;
constexpr int b = sizeof(T1);
if (a < b)
static_assert(sizeof(T1) != a - 1, "Error 1");
}
};
int main()
{
TestStruct1<short> t;
}
Тот же GPT не смог ответить правильно скомпилируется ли программа и почему. А может это еще и зависит от...
А вы сможете? Как вы это поймете? Просто догадаться нужно? А если кода сотни строк времени компиляции?
Здравствуйте, andrey.desman, Вы писали:
S>>А вы сможете? Как вы это поймете? Просто догадаться нужно? А если кода сотни строк времени компиляции?
AD>Попытка под runtime if затащить compile-time static_assert declaration. AD>Слишком много квалии для простого девелопера...
После запуска — стало очевидно. Однако никаких предупреждений я не получил при сборке. GPT тоже посчитал что if может быть выполнен на этапе компиляци:
При компиляции программы, включая прекомпиляцию (если используется), компилятор обрабатывает условные конструкции, в том числе if-условия. Однако, в данном случае, условие if (a < b) является константным выражением, которое можно вычислить во время компиляции.
Компилятор может проводить оптимизации на этапе прекомпиляции и поэтому в данном случае он может упростить и удалить условную конструкцию, так как она всегда имеет ложное условие.
В результате, компилятор будет обрабатывать только оставшуюся часть программы, которая не зависит от условия if (a < b). Таким образом, статическое утверждение static_assert не будет учтено компилятором, и программа скомпилируется успешно.
Однако, важно отметить, что различные компиляторы могут иметь разные уровни оптимизации и могут вести себя по-разному в подобных ситуациях. В общем случае, использование условий внутри статических утверждений может привести к непредсказуемому поведению и ошибкам компиляции.
Здравствуйте, Разраб, Вы писали:
S>>Вопрос в том как все это отлаживать? Р>Переходите на zig:
В языке главное — кодовая база. Когда кода много — его нужно кому-то поддерживать. Машина пока не умеет. Перевести код с одного языка на другой — тоже не умеет, тем более такой причудливый язык как ++.
Кодовая база — это ваш хлеб.
Какая кодовая база у zig? Много ли библиотек на нем написано?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Разраб, Вы писали:
S>>>Вопрос в том как все это отлаживать? Р>>Переходите на zig:
S>В языке главное — кодовая база. Когда кода много — его нужно кому-то поддерживать. Машина пока не умеет. Перевести код с одного языка на другой — тоже не умеет, тем более такой причудливый язык как ++.
S>Кодовая база — это ваш хлеб.
S>Какая кодовая база у zig? Много ли библиотек на нем написано?
Система сборки зига умеет компилить и си и кресты. сам зиг еще в стадии разработки. совместимость тоже есть. кросс компиляция из коробки.
вообщем по ссылке перевод фичей(там внизу страницы ссылки на переводы).
Здравствуйте, Разраб, Вы писали:
Р>Система сборки зига умеет компилить и си и кресты. сам зиг еще в стадии разработки. совместимость тоже есть. кросс компиляция из коробки. Р>вообщем по ссылке перевод фичей(там внизу страницы ссылки на переводы).
Основная работа все-равно будет — исправить баг в той или иной С++ -библиотеке, добавить некую новую функциональность. Нужно в первую очередь знать тот язык, на котором основная кодовая база.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Разраб, Вы писали:
Р>>Система сборки зига умеет компилить и си и кресты. сам зиг еще в стадии разработки. совместимость тоже есть. кросс компиляция из коробки. Р>>вообщем по ссылке перевод фичей(там внизу страницы ссылки на переводы).
S>Основная работа все-равно будет — исправить баг в той или иной С++ -библиотеке, добавить некую новую функциональность. Нужно в первую очередь знать тот язык, на котором основная кодовая база.
Я не в курсе, но разве ГПТ не может автоматом имея спецификацию двух ЯП сконвертировать код?
Здравствуйте, Разраб, Вы писали:
Р>Я не в курсе, но разве ГПТ не может автоматом имея спецификацию двух ЯП сконвертировать код?
На практике не работает. Он может небольшой кусок простого кода сконвертировать, и то часто с ошибками. Сконвертировать целый проект с учетом особенностей связанных библиотек, режимов сборки и т.д. — это уже нужен полноценный сильный интеллект, который вообще всех на свете лишит работы.
Я на С++ лишь любитель, так что моё мнение нужно воспринимать, конечно, аккуратно.
Лично я считаю, что код времени компиляции в общем случае это плохо.
Он уместен лишь в очень небольших объёмах там, где его использование очевидно, понятно и подчиняется неким общепринятым паттернам.
Тот же static assert идеален там, где и без него вылезет ошибка. Но со static_assert эта ошибка будет понятной, не на 5 экранов инстанцирования шаблонов, в которых потом полчаса будешь вкуривать, что, собственно, пошло не так.
А когда на коде времени компиляции делают, к примеру, полноценные парсеры, это полная дичь и таким даже пользоваться не стоит, не то, что самому такое делать.
Если хочется делать что-то сложное до компиляции, то надо генерировать исходный код. Т.е. написать отдельную программу, которая будет генерировать код. Вот и весь сказ. И эту отдельную программу можно уже отлаживать как душе угодно.
То, что что-то можно сделать, не означает, что это нужно делать.
И фактически один и тот же код будет работать. В том числе есть и GUI-приложения — есть кодовая база и библиотеки для этого.
Вот взять тот же .Net — в теории вроде можно для WebAssembly. Но почему-то размер бинаря в пол гигабайта, ну ладно в 200 Мб. — кажется великоватым.
Вот тот же Rust вроде хорош — а где кодовая база? Много ли на нем написали уже? Где гарантия что он будет востребован, а не уйдет в небытие, будучи заменен на Mojo или там zig.
Ведь дело не только в языке — важен объем кодовой базы.
Здравствуйте, Shmj, Вы писали:
S>Но, простите, как это отлаживать?
а что тут отлаживать? Оно же не компилиируется. Не компилируется из-за связки if + static_assert. Замените if на if constexpr
Если же ошибка в логике, тогда сложнее. В основном я отлаживаюсь выводами в cout и static_assert. Причём последний чтобы только удостовериться, что код может быть выполнен в compile time
Здравствуйте, Shmj, Вы писали:
S>Вот вроде бы все так безобидно начиналось — макросы. Ну это же, можно сказать, почти тупая замена текста. Ну ОК, добавили параметры макроса, это чуть более сложная замена текста. S>А сейчас что? Шаблоны, constexpr и иже с ними — это фактически урезанный C++ поверх C++ S>Но, простите, как это отлаживать? Если обычный С++ можно в дебагере пройтись по шагам и все станет ясно — то тут мы просто имеем ошибку без всякой возможности понять причину ее возникновения (окромя как догадаться). S>Тот же GPT не смог ответить правильно скомпилируется ли программа и почему. А может это еще и зависит от... S>А вы сможете? Как вы это поймете? Просто догадаться нужно? А если кода сотни строк времени компиляции?
Очередная "проблема", высосанная хер знает откуда, для того, чтоб пословоблудить.
P.S. И что, какой-то придурок тебе за это деньги платит?
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Shmj, Вы писали:
S>>Да и вообще код на C++ не пишите. Серьезно.
S>А на чем писать то?
Вы не с той стороны к снаряду подходите. Для аналогии: вы узнали про опасную бритву и решили, что это классный инструмент. Вот только этот инструмент противопоказан людям с тремором. А у вас тремор. Вам нельзя опасную бритву в руки брать.
Может у вас IQ 180, докторская степень по физике и куча открытий в квантовой механики. Может в каких-то областях вам вообще нет равных.
Но вот то, что и как вы пишете о программировании вообще (и о программировании на C++ в частности), наводит на мысль, что программированием на C++ вам лучше не заниматься. А то получится как вот здесь
ув.тов.netch80 написал.
S>На C++ можно написать сразу под 6 платформ:
Боюсь вас разочаровать, но изрядная часть софта на C++ разрабатывается всего под одну платформу. А какая-то часть и вообще под конкретную версию конкретной программно-аппаратной платформы.
S>Ведь дело не только в языке
Дело не в языке, дело в мозгах. Ну что поделать, если под C++ мозги не у всех заточены.
Здравствуйте, Shmj, Вы писали:
S>Вот вроде бы все так безобидно начиналось — макросы. Ну это же, можно сказать, почти тупая замена текста. Ну ОК, добавили параметры макроса, это чуть более сложная замена текста.
S>А сейчас что? Шаблоны, constexpr и иже с ними — это фактически урезанный C++ поверх C++
S>А вы сможете? Как вы это поймете? Просто догадаться нужно? А если кода сотни строк времени компиляции?
Кажется, я начинаю догадываться, как появляются мысли, что чёрных, гомосеков и нормальных должно быть в равном количестве на работе. Кто вообще сказал, что любой код можно пройти по шагам в отладчике? Есть тысячи вариантов, когда это невозможно, и ничего — как-то живут люди. Несколько примеров:
1. Что-то очень сильно аппаратное.
2. Код, который зависит от времени так, что любой останов в отладчике ломает алгоритм.
3. Распределённые системы.
4. Just-in-time компиляция.
5. Кодогенерация.
А тут простой compile-time: и static_assert можно использовать, и отладочная печать промежуточных значений, и вывод godbolt. Я хоть и негативно отношусь к С++ в целом, но вот этот наезд — вообще мимо.
Здравствуйте, cppguard, Вы писали:
C>Есть тысячи вариантов, когда это невозможно, и ничего — как-то живут люди. Несколько примеров:
C>1. Что-то очень сильно аппаратное. C>2. Код, который зависит от времени так, что любой останов в отладчике ломает алгоритм. C>3. Распределённые системы. C>4. Just-in-time компиляция. C>5. Кодогенерация.
Вспомнилось, как я когда-то ловил ошибку: проблема была в кривой синхронизации между потоками. Так вот и в отладчике не поймаешь, и, что самое подлое, любая отладочная печать вносила синхронизацию и ошибка переставала воспроизводиться. Это было в 2006 году, давненько уже, но в память врезалось хорошо.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, so5team, Вы писали:
S>Может у вас IQ 180, докторская степень по физике и куча открытий в квантовой механики. Может в каких-то областях вам вообще нет равных. S>Но вот то, что и как вы пишете о программировании вообще (и о программировании на C++ в частности), наводит на мысль, что программированием на C++ вам лучше не заниматься. А то получится как вот здесь
C++ просто объективно сложнее среднестатистического ЯП. Примерно в 3 раза:
+ добавляются указатели и управление памятью — это еще столько же времени, сколько полноценный ЯП
+ добавляются шаблоны и метапрограммирование — это еще один новый язык.
Тут не в том дело что мозги не подходят. Если у вас n лет опыта разработки, то второй язык освоите где-то за 3 месяца плотной работы. С++ потребует 9 месяцев плотной работы. У меня где-то месяца 3 набралось, т.к. работаю не плотно.
S>>На C++ можно написать сразу под 6 платформ:
S>Боюсь вас разочаровать, но изрядная часть софта на C++ разрабатывается всего под одну платформу. А какая-то часть и вообще под конкретную версию конкретной программно-аппаратной платформы.
Однако если вам потребуется кросс-платформа — то альтернатив фактически просто нет в нашем мире
Ну разве что голый C, но хрен редьки не слаще. На нем то тоже пишут в ООП-стиле, только велосипедят. А это еще хуже.
S>>Ведь дело не только в языке S>Дело не в языке, дело в мозгах. Ну что поделать, если под C++ мозги не у всех заточены.
Затачивать нужно где-то месяцев 9 после обычного ЯП.
