Использование ifdef не всегда уместно. И иногда нужно логическое значение для программы например подобное:
using iterator = std::conditional_t<DEBUG, Debug_iteratot, pointer>
Ну это например хотя да можно просто через ifdef, но кажется не всегда удобно для понимания, а тут как-то явнее.
И иногда нужно именно добавить функциональности или немного изменить структуру кода без вреда на итоговый результат кода хоть в debug хоть в release
Про assert я слышал, но как-то ещё не приходилось использовать. Он проверяет условие на истинность вроде и если ложно то вырубает программу насколько мне это известно, но это не совсем то. Все таки хочется обработать как-нибудь ошибку
Я знаю что при релизе нужно сделать DEBUG false я это заранее продумал
И я пробовал так делать используя константу, но тогда все COMMA, LOCATION, PARAMETER они работать не будут и компилятор будет жаловаться на это всё. Ведь сперва компилируются макросы, а уже потом константы
VoidVolker, Да это не совсем вопрос, просто чужое мнение хотелось бы выслушать по такому поводу. Может кто-нибудь подобное уже делал. Там могут ли проблемы какие-нибудь возникнуть. Я пробовал это обсуждать с нейросетями, но у них это впринципе зашито то что макросы это зло, хотя если спросить как добиться подобного эффекта то они подобный код и выдадут со словами пользуйтесь спокойно.
Та же беда бывает, тоже задавался этим вопросом. И на одном форуме нашёл переписку где подсказали искать не cppreference.com, а искать: cppreference.dev
Почему-то .dev нормально загружается и наполнение сайта почти полностью совпадает с .com
Задумка впринципе интересная, но у меня там в рабочем классе подразумевается много элементов (занимают память), которые выполняют какую-то сложную работу.
И я хотел избежать выделения не используемой памяти в случае если класс не нужен. У меня недавно появилось мысль создать класс Data и уже вызывать его через умный указатель с проверкой на существование Data.
Но в любом случае спасибо за новую мысль, о том как можно сделать подобные штуки. Только я не понял прикола с виртуальным методом doPrint.
auto это не тип, это просто программист говорит компилятору, чтобы он сам определил тип. Чтобы например не писать прогромисту длинную строку кода например:
xiinap, можешь добавить скрин полной твоей uv-развертки, и несколько скринов всей модели с разных сторон чтобы лучше понять, что именно не так. И у тебя там будет несколько текстур на одной модели или нет?
xiinap, ты там углубления в рёбрах сделал что ли? Просто на скринах я заметил только раму вокруг окон. А так вроде все остальное ровная поверхность. И лично я не особо вижу смысла в в таком количестве полигонов. Можно немного оптимизировать модель. А если ты реально там углубления сделал, то можно эти углубления с помощью normal map реализовать.
Ну это например хотя да можно просто через ifdef, но кажется не всегда удобно для понимания, а тут как-то явнее.
И иногда нужно именно добавить функциональности или немного изменить структуру кода без вреда на итоговый результат кода хоть в debug хоть в release
Про assert я слышал, но как-то ещё не приходилось использовать. Он проверяет условие на истинность вроде и если ложно то вырубает программу насколько мне это известно, но это не совсем то. Все таки хочется обработать как-нибудь ошибку