А чем макрос плох? Они в расте достаточно гибкие, чтобы сделать почти все что угодно. А как обкатают фичу и если нужда будет - можно и в язык запилить, как с try! было
Ну а насчет велосипедов.. "если никто не будет изобретать велосипеды, то они превратятся в непознаваемое наследие предков". Это может быть не очень полезно для проекта, но полезно для вас как специалиста :)
.. хм, в принципе, я реально предпочел бы enum вместо дефайнов почти всегда. По крайней мере если функция аргументом принимает enum - сразу видно возможные варианты, а вот если просто int - то уповать на документацию или ванговать
Выравнивание и единый стиль - для слабаков, которые не хотят вчитываться в ваш код. Заставьте их!
Побольше кода в заголовочных файлах (а лучше - весь в одном!), ведь так гораздо удобнее, а время компиляции возрастает очень незначительно.
Злые языки говорят, что goto считается вредным, но это чушь. Этот оператор очень мощен и способен заменить почти все другие конструкции языка, старайтесь пользоваться им почаще. А для переходов между функциями используйте setjmp/longjmp
Никогда не используйте enum'ы, они все равно неявно приводятся к int; используйте int напрямую!
Старайтесь писать документацию как можно подробнее, каждый метод, каждая функция должны быть снабжены развесистым комментарием. Но никогда не давайте примеров использования в документации, это дурной тон! Вы же не считаете пользователей вашего кода дураками?
Используйте как можно больше разных систем сборки и пакетных менеджеров, покажите, что вы в курсе современных тенденций! Разумеется, версии кода в пакетах для разных менеджеров должны быть немного разными, иначе пользователи заскучают.
Вы ведь слышали, что стандартные примитивные типы в С и С++ не имеют гарантированной длины в битах? Чтобы справится с этой проблемой лучше всего завести свои псевдонимы для примитивных типов, с указанной фиксированной длиной. Ни в коем случае не пользуйтесь типами из stdint.h, ведь существование этого файла не гарантируется стандартом, а значит, ваш код не будет действительно переносимым!
Проявите немного уважения к программистам прошлого, объявляйте все переменные вначале функций. Это - традиция!
Использовать венгерскую нотацию - тоже хорошая, проверенная временем практика; посмотрите в конце концов на WinAPI
Ну так а как значения-то подставлены будут?
Интересно.. т.е. это преобразование заменяет имена переменных в строке на позиционные аргументы для String.Format?
оО А как там это работает?
._.
Но это пока, вроде как ничего не мешает - концептуально - этому работать точно так же в макросе. Просто пока не сделали.
Допилить макрос, мне кажется, существенно проще, чем допилить компилятор.
Но позвольте, тут в итоге больше на один восклицательный знак..
println!("Hello, {person}!"); - это же сам println делает, будь это встроено в язык - что бы поменялось?
А чем макрос плох? Они в расте достаточно гибкие, чтобы сделать почти все что угодно. А как обкатают фичу и если нужда будет - можно и в язык запилить, как с try! было
Ну, в компайл-тайм - да.
Прост я не припомню нигде в компилируемых языках ничего подобного, это нужно чтоб макрос мог строковый литерал разбирать.
А разве это вообще возможно в компилируемом языке?
Я сходу не представляю, как это сделать, не таща в каждый бинарник мини-компилятор или не навешивая на все переменные море мета-информации.
Вообще говоря, конечно, может зависеть, ведь стандарт не оговаривает как именно реализуются стандартные алгоритмы..
Но видимо у меня какие-то фантомные воспоминания (или я с чем-то другим путаю), сейчас посмотрел стектрейс на том компиляторе, получил:
std::__lower_bound⟨int*, int, __rw::__rw_lt⟨int⟩, int⟩(T1, T1, const T2&, T3, T4*, std::random_access_iterator_tag) ⇒ __rw::__rw_lt⟨int⟩::operator ()(const int&, const int&) constИ 96 байт стека; по воспоминаниям было как-то сильно больше, но тот проект давно канул в Лету, так что признаю свою неправоту :)
std::array-то почему нет?
Кстати, есть еще такая штука - https://www.etlcpp.com
Видимо, зависит от реализации std, я сходу не помню, но в моей почему-то было очень много вложенных вызовов каких-то вспомогательных
Есть std::binary_search :) Но по моему опыту он очень хорошо стек кушает
Это просто первая же ссылка в гугле, если что :)
Ну а насчет велосипедов.. "если никто не будет изобретать велосипеды, то они превратятся в непознаваемое наследие предков". Это может быть не очень полезно для проекта, но полезно для вас как специалиста :)
Не думали использовать хэшмап в компайл-тайме? Например, https://github.com/mapbox/eternal
Поскольку добавлять или удалять узлы не нужно, снимаются вопросы с управлением памятью, а look-up константный.
Вот насчет коллизий не знаю, но, наверное можно что-то придумать (static_assert выдавать, например :)
Пфф, зачем так много печатать, если есть С-style-cast?
.. хм, в принципе, я реально предпочел бы enum вместо дефайнов почти всегда. По крайней мере если функция аргументом принимает enum - сразу видно возможные варианты, а вот если просто int - то уповать на документацию или ванговать
Выравнивание и единый стиль - для слабаков, которые не хотят вчитываться в ваш код. Заставьте их!
Побольше кода в заголовочных файлах (а лучше - весь в одном!), ведь так гораздо удобнее, а время компиляции возрастает очень незначительно.
Злые языки говорят, что goto считается вредным, но это чушь. Этот оператор очень мощен и способен заменить почти все другие конструкции языка, старайтесь пользоваться им почаще. А для переходов между функциями используйте setjmp/longjmp
Никогда не используйте enum'ы, они все равно неявно приводятся к int; используйте int напрямую!
Старайтесь писать документацию как можно подробнее, каждый метод, каждая функция должны быть снабжены развесистым комментарием. Но никогда не давайте примеров использования в документации, это дурной тон! Вы же не считаете пользователей вашего кода дураками?
Используйте как можно больше разных систем сборки и пакетных менеджеров, покажите, что вы в курсе современных тенденций! Разумеется, версии кода в пакетах для разных менеджеров должны быть немного разными, иначе пользователи заскучают.
Вы ведь слышали, что стандартные примитивные типы в С и С++ не имеют гарантированной длины в битах? Чтобы справится с этой проблемой лучше всего завести свои псевдонимы для примитивных типов, с указанной фиксированной длиной. Ни в коем случае не пользуйтесь типами из
stdint.h, ведь существование этого файла не гарантируется стандартом, а значит, ваш код не будет действительно переносимым!Проявите немного уважения к программистам прошлого, объявляйте все переменные вначале функций. Это - традиция!
Использовать венгерскую нотацию - тоже хорошая, проверенная временем практика; посмотрите в конце концов на WinAPI
Существует стандартная именованная константа UINT8_MAX :)
Возможно, если бы в коде была она, а не просто число 255, вопросов было бы чуть меньше (но не факт, конечно)
Это другой вопрос :)