Еще советую про genfft прочитать, это такой специализированный компилятор для преобразований фурье, завязанный на всякие там символьные вычисления к тому же http://www.fftw.org/fftw-paper-ieee.pdf
FFTW’s codelets are generated automatically by a special-purpose compiler called genfft. Most users do not interact with genfft at all: the standard FFTW distribution contains a set of about 150 pre-generated codelets that cover the most common uses. Users with special needs can use genfft to generate their own codelets. genfft is useful because of the following features. From a high-level mathematical description of a DFT algorithm, genfft derives an optimized implementation automatically.
А, ну и управление ресурсами еще. Чтобы автоматом оборачивать код использующий ресурс в try/catch и _гарантированно_ освобождать его после. В питоне для этого ввели целую специальную синтаксическую структуру.
А, ну и управление ресурсами еще. Чтобы автоматом оборачивать код использующий ресурс в try/catch и _гарантированно_ освобождать его после. В питоне для этого ввели целую специальную синтаксическую структуру.
А в С++ для этого ввели деструкторы и переменные на стеке, и это гораздо удобней чем «специальные синтаксические структуры» и пр.
Standard specializations for library types
std::hash<std::string>
std::hash<std::u16string>
std::hash<std::u32string>
std::hash<std::wstring>
hash support for strings
(class template specialization)
std::hash<std::error_code>
hash support for std::error_code
(class template specialization)
std::hash<std::bitset>
hash support for std::bitset
(class template specialization)
std::hash<std::unique_ptr>
hash support for std::unique_ptr
(class template specialization)
std::hash<std::shared_ptr>
hash support for std::shared_ptr
(class template specialization)
std::hash<std::type_index>
hash support for std::type_index
(class template specialization)
std::hash<std::vector<bool>>
hash support for std::vector<bool>
(class template specialization)
std::hash<std::thread::id>
hash support for std::thread::id
(class template specialization)
Все, tuple или pair от двух типов, для которых хеш определен я тут не вижу.
Ты настолько неудачник по жизни что сразу вопишь «Ты идиот?» каждому незнакомому человеку?
Складывается впечатление, что вы хотите от языка общего назначения получить функциональность специализированного инструмента, заточенного под конкретную предметную область.
Взять, например, упрощение арифметических выражений. По хорошему, вам нужен некий язык, для которого вы пишете свой собственный оптимизирующий транслятор (который преобразует выражения вида (a+a+a+a)/a в конкретный результат 4). Сейчас вы можете спокойно его сделать посредством какого-то генератора парсеров вроде ANTLR. А результат работы транслятора выдавать в виде C++, дабы затем над сгенерированным вами C++ным кодом поработал оптимизирующий C++ный компилятор.
Но вы этого не хотите по каким-то причинам. А хотите, чтобы такую возможность вам дал именно C++ный компилятор.
Точка зрения понятна.
Вопрос в том, какое количество C++ных разработчиков разделяют вашу точку зрения. И достаточно ли их (т.е. таких как вы) дабы оформить соответствующее предложение для включение в стандарт.
Я хочу чтобы мне было достаточно знать один язык, и расширять его настолько, насколько мне нужно, а не задействовать некие сторонние кодогенераторы(которые еще надо изучать).
Вопрос в том, какое количество C++ных разработчиков разделяют вашу точку зрения.
C++ не пригоден для доработки под такое. Надо делать новый ЯП чтоб как в лиспе, чтоб я мог с AST на этапе компиляции макросами как угодно работать с кодом, добавлять там систему символьных вычислений чтобы она мне код могла переиначивать как надо
Еще и еще раз, медленно, посчитать хеш для произвольных данных - это не то, что должен делать std::hash. std::hash должен вернуть одинаковое значение для объектов, которые равны между собой, но не обязаны хранить общие данные.
Я хочу чтобы мне было достаточно знать один язык, и расширять его настолько, насколько мне нужно, а не задействовать некие сторонние кодогенераторы(которые еще надо изучать).
Чудес не бывает. Посмотрите внимательно на историю развития языков и на то, что в итоге осело в мейнстриме (принадлежность к мейнстриму означает так же более высокое качество инструментария). Больно мощные инструменты не стреляют по разным причинам.
Надо делать новый ЯП чтоб как в лиспе, чтоб я мог с AST на этапе компиляции макросами как угодно работать с кодом, добавлять там систему символьных вычислений чтобы она мне код могла переиначивать как надо
Имхо, если бы вам это было действительно нужно, то необходимый инструментарий для подручных средств вы бы уже давным-давно сделали.
std::hash основан на специализациях. Например если для того же std::string хеш будет определен, то достаточно считать murmur hash от хешей, комбинируя tuple из строк. Если есть желание заморачиваться другим способом, то можно просто побайтово кормить в murmur строки одна за другой, но это уже специальная реализация
Это как сказать что, чтоб посчитать hash для класса - достаточно считать murmur hash от полей. И тогда вообще специализировать std::hash не надо т.к. все упрется в базовые типы.
Никак. У меня нет времени прочитать PDF-ку на 16-ть страниц с двумя колонками текста на каждой :(
А из просмотра первой страницы не понятно, что и как именно люди сделали.
Такое нужно делать умно, например заставлять пользователя явно перечислить хешируемые поля, особенно обьяснить что делать с указателями или внутренними класами. Так часто делают. Вот псевдокод например на жабе.
int hashCode() {
return Hasher.add(name).add(lastname).add(account.reference);
}
String name;
String lastname;
Account account;
long transientTimerValue;
(принадлежность к мейнстриму означает так же более высокое качество инструментария)
Нет, не означает. Вспомните PHP, или JavaScript например, который за 10 создали вообще. И этот JavaScript используют оттого, что это единственный ЯП который умеют все современные браузеры, других альтернатив попросту нет (всякие флешплагины и жава-апплеты не в счет, они далеко не везде есть) и оттого в этот JS компилируют другие языки. Популярность != качество.
Не то что не надо, но решение применять его или нет должно лежать за разработчиком в каждом конкретном случае. Если был std::cow_vector рядом где-то, то он бы никому не мешал.
Даже 3 сек на стековерфлоу позволяют обьяснить как сделать хеш для комбинаций типов
tuple в частном случае можно рассматривать как структуру, а то, что нельзя автоматом генерировать хеш по полям структуры/класса я уже писал. Это и то, что часть полей могут меняться, при том, что они явно не влияют на сравнение, и то, что часть полей надо вообще игнорировать.
Да ладно. Возьмите качество оптимизаторов у «взрослых» С++ных компиляторов, вроде Intel, GCC, Clang или даже VC++. Много ли найдется трансляторов для других нативных языков со сравнимым качеством?
Вспомните PHP, или JavaScript например, который за 10 создали вообще.
Про PHP ничего не скажу, но вот виртуальную машину для JavaScript вылизывают уже не первый год. И в ряду интерпретируемых динамических языков с VM современный JavaScript далеко не аутсайдер.
В аналогах std::tuple во всех известных языках просто применяется хеш для ВСЕХ типов, потому что на практике это очень часто ключ хеш-таблицы. Никто не умер. Это очень ожидаемо. И не надо никакой автоматики для всех классов, но tuple/pair - очень очевидные кандидаты. Учитывая количество boilerplate для специализации hash
но вот виртуальную машину для JavaScript вылизывают уже не первый год.
Если б в браузере вместо JavaCript всунули б какой-нибудь PascalScript, его б точно так же вылизывали. Заслуги «качественности» языка тут нет никакой. Если есть какой-то язык который используется в вебе, и надо чтоб он быстро работал, интерпретаторы и JIT-ы для него надо оптимизировать, неважно плохой он или хороший. https://habrahabr.ru/post/106274/
Если б в браузере вместо JavaCript всунули б какой-нибудь PascalScript, его б точно так же вылизывали.
У меня такое впечатление, что вы хотите жить в каком-то вымышленном мире. История уже пошла так, как она пошла. И вместо PascalScript есть JavaScript, который даже в браузерах более вменяемые альтернативы вроде TypeScript или Dart подвинуть не могут.
И если смотреть на то, что есть, то инструментарий для JavaScript, в частности, его VM, будет качеством повыше, чем для какого-нибудь Ruby.
Посему, если смотреть на реальный мир, то можно либо приспособиться к тому, что есть (что, кстати говоря, и сделали авторы genfft), либо пытаться менять его создавая более удобные, по-вашему мнению, инструменты.
Однако, создание и продвижение собственного инструмента, могу вас уверить, дело долгое, сложное и неблагодарное. С очень низкими шансами на успех.
А посему, вместо форумных сетований про отсутствие метапрограммирования в крестах можно освоить тот же ANTLR или CoCo/R и упростить себе жизнь здесь и сейчас.