Но как Вы в этом случае будете реализовывать функцию подсчёта хэша, работающую во время компиляции?
Ведь аргументы макроса CASE могут встречаться в коде где угодно…
Да, извиняюсь, я спутал с шифрованием вроде MD5. А Perfect hash реализовать можно, но для этого придётся при добавлении строки в CASE заодно добавлять эту строку в функцию вычисления хэша.
Конечно, я рассматривал и perfect hash. С его применением ограничения вообще бы не чувствовались :)
Однако потом посчитал, что отсутствие коллизий важнее. Ведь данные макросы может использовать человек, который и не подозревает, что в них идёт вычисление хэша… И коллизии могут быть очень некстати, даже если вероятность их возникновения минимальна.
Хотя, конечно, функцию str_hash можно переделать на всё что угодно.
Кстати, да — ведь при возведении 128 в степень и впрямь можно использовать битовую арифметику, хотя на результат это не повлияет. Я про это что-то не подумал, спасибо за уточнение. Надо будет файл обновить.
Что касается эскейп-последовательностей в case — лично у меня GCC на них кидает варнинг при компиляции, так что программист их заметит. В крайнем случае, можно изменить функцию str_is_correct на диапазон 0-126 — тогда точно можно быть спокойным.
финальный модификатор const после списка параметров — мой самый любимый. Он указывает на то, что idSurface::Split() не будет изменен самой поверхностью (surface).
Небольшая неточность: не «не будет изменен самой поверхностью», а «не будет изменять саму поверхность».
Автор имеет в виду, что const-метод не может менять объект, для которого вызван. Хотя полностью надеяться на это нельзя, поскольку mutable-переменные никто не отменял.
За последние 6 недель разработки Dyad я дописал 13k строк кода.
Вот это скорость! При стандартном 8-часовом рабочем дне получается примерно 1 строчка кода в минуту.
Видимо, проект так нравился автору, что он его и дома не оставлял ;)
А какие преимущества, интересно, даст D по сравнению с C++11 для этого фреймворка? Если учесть то, что Qt и так его расширяет — те же проперти, сигналы/слоты, QtConcurrent…
Сборка мусора не в счёт — хватает смарт-пойнтеров, которые эту проблему решают.
Да, извиняюсь, нужно было конкретизировать — я имел в виду iOS и Android, как самые популярные ныне мобильные платформы. Да и под ВинФон также хочется.
Если Вам в C++ не нравится какой-то механизм — не используйте его, только и всего.
Никто не заставляет Вас пользоваться rValue-ссылками — можете использовать обычные lValue.
Более того, никто не заставляет пользоваться ссылками вообще — можете везде юзать указатели, как в старом добром С.
rValue-ссылки — это прекрасный способ полноценного использования временного объекта. Благодаря нему, в частности, в С++11 инициализация STL-ных контейнеров происходит куда быстрее, нежели в старом C++03 — поскольку для объектов, «заполняющих» контейнер, теперь вызывается не контруктор копирования, а констуктор перемещения.
А если в других языках подобных «извращений» нету — то это вовсе не значит, что эти языки лучше С++. Это значит лишь то, что С++ даёт программисту больший контроль над ситуацией, чем эти языки.
Ведь аргументы макроса CASE могут встречаться в коде где угодно…
Однако потом посчитал, что отсутствие коллизий важнее. Ведь данные макросы может использовать человек, который и не подозревает, что в них идёт вычисление хэша… И коллизии могут быть очень некстати, даже если вероятность их возникновения минимальна.
Хотя, конечно, функцию str_hash можно переделать на всё что угодно.
Что касается эскейп-последовательностей в case — лично у меня GCC на них кидает варнинг при компиляции, так что программист их заметит. В крайнем случае, можно изменить функцию str_is_correct на диапазон 0-126 — тогда точно можно быть спокойным.
Однако возможно использование mutable-переменных или различных const_cast, так что на 100% «константному методу» доверять нельзя.
Автор имеет в виду, что const-метод не может менять объект, для которого вызван. Хотя полностью надеяться на это нельзя, поскольку mutable-переменные никто не отменял.
Вот это скорость! При стандартном 8-часовом рабочем дне получается примерно 1 строчка кода в минуту.
Видимо, проект так нравился автору, что он его и дома не оставлял ;)
Погостила на Земле, и хватит — пускай отправляется на родину.
P.S. Про нано-ботов в крови там тоже, кстати, было.
Сборка мусора не в счёт — хватает смарт-пойнтеров, которые эту проблему решают.
Совмещение Qt5 и C++11 должно дать высокую скорость работы и настоящую кросс-платформенность. Неужели всё действительно будет так шикарно?
Никто не заставляет Вас пользоваться rValue-ссылками — можете использовать обычные lValue.
Более того, никто не заставляет пользоваться ссылками вообще — можете везде юзать указатели, как в старом добром С.
rValue-ссылки — это прекрасный способ полноценного использования временного объекта. Благодаря нему, в частности, в С++11 инициализация STL-ных контейнеров происходит куда быстрее, нежели в старом C++03 — поскольку для объектов, «заполняющих» контейнер, теперь вызывается не контруктор копирования, а констуктор перемещения.
А если в других языках подобных «извращений» нету — то это вовсе не значит, что эти языки лучше С++. Это значит лишь то, что С++ даёт программисту больший контроль над ситуацией, чем эти языки.