Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
E>>>Принцип раздельной компиляции мешает определять id типов до загрузки всех модулей...
__>>Erop, я вас, по традиции, с первого раза не могу понять. я имел в виду, что мешает в стандарт ввести, что идентификатор uint8 — 0, uint16 — 1, float — 2 и т.п. и организовать compile-time type_trait<type>::uid?
E>А с std::vector<float> что делать?
я вел речь, как и топикстартер, о встроенных простых типах.
Здравствуйте, watchmaker, Вы писали:
BZ>>тут дело не в алгоритме хеширования. 26^10 > 2^32. W>Это да. Я криво написал. Не столь важно, какой конкретно из алгоритмов используется (MurmurHash или FNV-1a), а то что для этого используется независимое хеширование, а не альтернативный подход вроде этого
.
BZ>>в целом, если у тебя 10+ тыщ типов, то вероятность коллизии будет достаточно велика W>А могли бы и link-time PHF реализовать. Отсрочив появление коллизий на куда как более далёкие времена.
а с 128 битами вероятность коллизии будет меньше вероятности аппаратного сбоя при сравнении для справки, разные виды памяти имеют вероятность сбоя от 1e-10 до 1e-20
Это не особо надо, их же можно перечислить явно в тритсах каких-нибудь. Но не ясно зачем это надо...
Вот если бы можно было отражать любые типы, или любые типы из произвольного набора и т. д...
Ну и потом, указатель -- простой встроенный? Указатель на поле? И т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
E>Это не особо надо, их же можно перечислить явно в тритсах каких-нибудь. Но не ясно зачем это надо...
там же начнется головная боль с алиазами (считать uint8_t и char псевдонимами друг друга или нет?). да и зачем меня нагружать этой рутиной, когда могли бы в тайптрейтс (если это так просто) засунуть?
а нужно, например, для того, чтобы сократить код для динамического приведения типов (в том же union или arithmetic_variant)
E>Вот если бы можно было отражать любые типы, или любые типы из произвольного набора и т. д...
а это зачем? просто, имхо, значения сложных типов редко когда корректно приводятся друг к другу
E>Ну и потом, указатель -- простой встроенный? Указатель на поле? И т. д...
нет. простые (базовые, фундаментальные) — это те, которые не предполагают в своем определении задействования других типов.
Здравствуйте, _hum_, Вы писали:
__>а нужно, например, для того, чтобы сократить код для динамического приведения типов (в том же union или arithmetic_variant)
А если мне надо ещё и своё длинное целое, рациональное или с фиксированной точкой добавить?
Это противоречит концепции С++, что библиотечные типы не хуже/лучше пользовательских...
__>а это зачем? просто, имхо, значения сложных типов редко когда корректно приводятся друг к другу
Ну указатели на них часто, например...
А ещё вот такая конструкция, как std::vector<int>& в std::vector<const int>& тебе?
__>нет. простые (базовые, фундаментальные) — это те, которые не предполагают в своем определении задействования других типов.
Ну это очень мало типов просто. Что делать с 64-битным целым, а со 128-битным, например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
__>>а нужно, например, для того, чтобы сократить код для динамического приведения типов (в том же union или arithmetic_variant) E>А если мне надо ещё и своё длинное целое, рациональное или с фиксированной точкой добавить? E>Это противоречит концепции С++, что библиотечные типы не хуже/лучше пользовательских...
это как? не понял. разве вы можете добавить свои фундаментальные (не использующие в своем определении другие типы) типы?
насколько я себе представлял, вы можете только построить на основе уже существующих свои (наподобие, использовать class CFixedPointReal{uint16_t m_val; <набор операторов>}, чтобы организовать тип вещественных чисел с фиксированной точкой. но это уже будет не фундаментальный тип)
__>>а это зачем? просто, имхо, значения сложных типов редко когда корректно приводятся друг к другу E>Ну указатели на них часто, например...
разве часто? а можно пример?
E>А ещё вот такая конструкция, как std::vector<int>& в std::vector<const int>& тебе?
в каком смысле? при чем здесь вектор?
__>>нет. простые (базовые, фундаментальные) — это те, которые не предполагают в своем определении задействования других типов.
E>Ну это очень мало типов просто. Что делать с 64-битным целым, а со 128-битным, например?
Здравствуйте, _hum_, Вы писали:
__>насколько я себе представлял, вы можете только построить на основе уже существующих свои (наподобие, использовать class CFixedPointReal{uint16_t m_val; <набор операторов>}, чтобы организовать тип вещественных чисел с фиксированной точкой. но это уже будет не фундаментальный тип)
в твоём понимании фундаментальный или нет?
__>разве часто? а можно пример?
Ну там база к потомку, брат к брату через dyn_cast и т. д...
E>>А ещё вот такая конструкция, как std::vector<int>& в std::vector<const int>& тебе?
__>в каком смысле? при чем здесь вектор?
Ну если хочу так привести, то что делать?
__>>>нет. простые (базовые, фундаментальные) — это те, которые не предполагают в своем определении задействования других типов.
Это оно:
enum FType { zerro, one, two };
?
__>есть же вроде uint64_t
Ну он же где-то есть, а где-то надо то, что ты называешь нефундаментальный писать...
Обычный С++-код такую операцию переносит легко...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
__>>насколько я себе представлял, вы можете только построить на основе уже существующих свои (наподобие, использовать class CFixedPointReal{uint16_t m_val; <набор операторов>}, чтобы организовать тип вещественных чисел с фиксированной точкой. но это уже будет не фундаментальный тип)
E>Вот, скажем, IntRange<5, 65000>
конечно, нет, потому что его значения строятся на базе значений типа int (вы не сможете определить этот тип без использования int)
__>>разве часто? а можно пример? E>Ну там база к потомку, брат к брату через dyn_cast и т. д...
это только для объектов наследуемых классов. да и то, наверное, считается не лучшим кодом (для этого есть механизм виртуальных функций)
E>>>А ещё вот такая конструкция, как std::vector<int>& в std::vector<const int>& тебе?
__>>в каком смысле? при чем здесь вектор?
E>Ну если хочу так привести, то что делать?
я все-таки не понял, к чему вы клоните. я же говорю, с производными сложными типами приведение работает плохо (и, имхо, не нужно в большинстве случаев).
__>>>>нет. простые (базовые, фундаментальные) — это те, которые не предполагают в своем определении задействования других типов. E>Это оно:
enum FType { zerro, one, two };
?
нет, не оно. enum использует подоснову int.
__>>есть же вроде uint64_t E>Ну он же где-то есть, а где-то надо то, что ты называешь нефундаментальный писать... E>Обычный С++-код такую операцию переносит легко...
речь не об этом, а о том, что есть кирпичики (фундаментальные типы), на базе которых можно построить все остальное.
и достаточно наделить эти кирпичики расширенными возможностями (как то идентификацией типов), чтобы это можно было протащить, при надобности, дальше.
Здравствуйте, _hum_, Вы писали:
__>конечно, нет, потому что его значения строятся на базе значений типа int (вы не сможете определить этот тип без использования int)
Что значит "использования"?
Я могу сделать такой же нешаблонный, где нигде тип int использоваться не будет...
__>это только для объектов наследуемых классов. да и то, наверное, считается не лучшим кодом (для этого есть механизм виртуальных функций)
Это утверждение более чем спорное...
__>>>>>нет. простые (базовые, фундаментальные) — это те, которые не предполагают в своем определении задействования других типов. E>>Это оно:
enum FType { zerro, one, two };
?
__>нет, не оно. enum использует подоснову int.
Этот не использует...
__>речь не об этом, а о том, что есть кирпичики (фундаментальные типы), на базе которых можно построить все остальное. __>и достаточно наделить эти кирпичики расширенными возможностями (как то идентификацией типов), чтобы это можно было протащить, при надобности, дальше.
Не понятно, как тащить дальше совместимым образом. А без этого оно не особо надо.
Ну и нет проблем через трится "фунламентальным" типам ID назначить...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, x-code, Вы писали:
XC>Для всех числовых типов необходимо внутри функции получить некий константный индекс, однозначно соответствующий типу T.
Может, не надо изобретать велосипед?
В STL есть кортеж.
В STL есть функция get().
Вот тебе готовый индекс типа:
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
__>>конечно, нет, потому что его значения строятся на базе значений типа int (вы не сможете определить этот тип без использования int) E>Что значит "использования"? E>Я могу сделать такой же нешаблонный, где нигде тип int использоваться не будет...
хотелось бы взглянуть
__>>это только для объектов наследуемых классов. да и то, наверное, считается не лучшим кодом (для этого есть механизм виртуальных функций)
E>Это утверждение более чем спорное...
(ваш любимый смайлик )
__>>>>>>нет. простые (базовые, фундаментальные) — это те, которые не предполагают в своем определении задействования других типов. E>>>Это оно:
enum FType { zerro, one, two };
?
__>>нет, не оно. enum использует подоснову int. E>Этот не использует...
использует:
An enumeration is a distinct type whose value is restricted to a range of values (see below for details), which may include several explicitly named constants ("enumerators"). The values of the constants are values of an integral type known as the underlying type of the enumeration. cppreference.com/enumeration declaration
__>>речь не об этом, а о том, что есть кирпичики (фундаментальные типы), на базе которых можно построить все остальное. __>>и достаточно наделить эти кирпичики расширенными возможностями (как то идентификацией типов), чтобы это можно было протащить, при надобности, дальше.
E>Не понятно, как тащить дальше совместимым образом. А без этого оно не особо надо.
раз люди просят, значит, надо
E>Ну и нет проблем через трится "фунламентальным" типам ID назначить...
уже ж выше говорил об этом
там же начнется головная боль с алиазами (считать uint8_t и char псевдонимами друг друга или нет?). да и зачем меня нагружать этой рутиной, когда могли бы в тайптрейтс (если это так просто) засунуть?
Здравствуйте, tstalker, Вы писали:
T>Здравствуйте, x-code, Вы писали:
XC>>Для всех числовых типов необходимо внутри функции получить некий константный индекс, однозначно соответствующий типу T.
T>Может, не надо изобретать велосипед? T>В STL есть кортеж. T>В STL есть функция get(). T>Вот тебе готовый индекс типа: T>
Здравствуйте, _hum_, Вы писали:
__>хотелось бы взглянуть
На что? Берёшь и пишешь с конкретными константами тоже самое...
__>
__>An enumeration is a distinct type whose value is restricted to a range of values (see below for details), which may include several explicitly named constants ("enumerators"). The values of the constants are values of an integral type known as the underlying type of the enumeration.
__>cppreference.com/enumeration declaration
ну и? "некий целочисленный тип". Почему int-то?
Да, это тип для работы с числами, такой же как short, наример. Чем он менее "фундаментальный" чем short?
__>раз люди просят, значит, надо
Опять же не понятно, что мешает людям написать библиотеку тритсов для исчерпывающего перечня типов... __>
__>там же начнется головная боль с алиазами (считать uint8_t и char псевдонимами друг друга или нет?). да и зачем меня нагружать этой рутиной, когда могли бы в тайптрейтс (если это так просто) засунуть?
Во-первых, если совсем уж заморочиться, то можно шаблонной магией это порешать.
Во-вторых, если не страдать перфекционизмом, можно через условную компиляцию/версии хедеров для разных платформ/компиляторов сделать.
Только тут есть проблема. uint8_t нифига не "фундаментальный" тип в твоих понятиях, так что тока char, signed char и unsigned char...
Но, опять же, есть две независимые системы типов.
char, short, int, long, long long
и
int8_t, int_16_t, int32_t, int64_t...
Люди кторую из системов просят перенумеровать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
__>>хотелось бы взглянуть
E>На что? Берёшь и пишешь с конкретными константами тоже самое...
__>>
__>>An enumeration is a distinct type whose value is restricted to a range of values (see below for details), which may include several explicitly named constants ("enumerators"). The values of the constants are values of an integral type known as the underlying type of the enumeration.
__>>cppreference.com/enumeration declaration
E>ну и? "некий целочисленный тип". Почему int-то?
Ну это же не принципиально (просто в VS было именно так — по умолчанию шел int). Главное, что enum как тип обязательно привязан к другому типу, а значит, не является фундаментальным (что вы пытались оспорить).
E>Да, это тип для работы с числами, такой же как short, наример. Чем он менее "фундаментальный" чем short?
Если речь про enum, то я уже выше дал определение фундаментальности — независимость определения типа от других типов. Enum заивисит, а значит, не является фундаментальным.
__>>раз люди просят, значит, надо E>Опять же не понятно, что мешает людям написать библиотеку тритсов для исчерпывающего перечня типов... __>>
__>>там же начнется головная боль с алиазами (считать uint8_t и char псевдонимами друг друга или нет?). да и зачем меня нагружать этой рутиной, когда могли бы в тайптрейтс (если это так просто) засунуть?
E>Во-первых, если совсем уж заморочиться, то можно шаблонной магией это порешать.
Это не поможет. Проблема-то именно в многообразии типов и не совсем прозрачной их операционной семантике (тот же chsr в VS может в зависимости от настроек проекта идти как unsigned char или signed char).
E>Во-вторых, если не страдать перфекционизмом, можно через условную компиляцию/версии хедеров для разных платформ/компиляторов сделать.
E>Только тут есть проблема. uint8_t нифига не "фундаментальный" тип в твоих понятиях, так что тока char, signed char и unsigned char...
Почему не фундаментальный-то? Это, насколько я понимаю, псевдоним для unsigned char.
E>Но, опять же, есть две независимые системы типов. E>char, short, int, long, long long E>и E>int8_t, int_16_t, int32_t, int64_t... E>Люди кторую из системов просят перенумеровать?
Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково.
Здравствуйте, _hum_, Вы писали:
E>>Да, это тип для работы с числами, такой же как short, наример. Чем он менее "фундаментальный" чем short?
__>Если речь про enum, то я уже выше дал определение фундаментальности — независимость определения типа от других типов. Enum заивисит, а значит, не является фундаментальным.
Так чем short более фундаментален, чем
enum { start = 0, end = 10000 };
?
И то и то поддерживается процессором, и то и то числа, поддиапазон int, и то и то занимает 2 байта...
__>Это не поможет. Проблема-то именно в многообразии типов и не совсем прозрачной их операционной семантике (тот же chsr в VS может в зависимости от настроек проекта идти как unsigned char или signed char).
И что? Это шаблонной магии не мешает..
E>>Во-вторых, если не страдать перфекционизмом, можно через условную компиляцию/версии хедеров для разных платформ/компиляторов сделать.
E>>Только тут есть проблема. uint8_t нифига не "фундаментальный" тип в твоих понятиях, так что тока char, signed char и unsigned char...
__>Почему не фундаментальный-то? Это, насколько я понимаю, псевдоним для unsigned char.
Тогда я совсем не понимаю, что ты называешь "фундаментальный"...
Псевдоним у тебя фундаментальный, а enum нет?
Если вернуться к стандарту и его "встроенным" типам, то enum и указатель — встроенные...
__>Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково.
Ну это фигня. Легко делается. Вот если ты ещё потребуешь, что бы если номер разнй, то будут вести по-разному, то будет хуже...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, _hum_, Вы писали:
__>ага, а как же unsigned char и signed char, uint8_t, int8_t, short и прочие. вы уверены, что они все будут разные типы на всех платформах?
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
E>>>Да, это тип для работы с числами, такой же как short, наример. Чем он менее "фундаментальный" чем short?
__>>Если речь про enum, то я уже выше дал определение фундаментальности — независимость определения типа от других типов. Enum заивисит, а значит, не является фундаментальным.
E>Так чем short более фундаментален, чем
enum { start = 0, end = 10000 };
? E>И то и то поддерживается процессором, и то и то числа, поддиапазон int, и то и то занимает 2 байта...
__>>Это не поможет. Проблема-то именно в многообразии типов и не совсем прозрачной их операционной семантике (тот же chsr в VS может в зависимости от настроек проекта идти как unsigned char или signed char). E>И что? Это шаблонной магии не мешает..
ну, тогда я не понимаю, что вы имеете в виду...
E>>>Во-вторых, если не страдать перфекционизмом, можно через условную компиляцию/версии хедеров для разных платформ/компиляторов сделать.
E>>>Только тут есть проблема. uint8_t нифига не "фундаментальный" тип в твоих понятиях, так что тока char, signed char и unsigned char...
__>>Почему не фундаментальный-то? Это, насколько я понимаю, псевдоним для unsigned char.
E>Тогда я совсем не понимаю, что ты называешь "фундаментальный"...
Опять же, если ссылаться на cppreference.com
Objects, references, functions including function template specializations, and expressions have a property called type, which both restricts the operations that are permitted for those entities and provides semantic meaning to the otherwise generic sequences of bits.
то есть, в с++
тип = множество значений + множество допустимых операций над этими значениями (включая оперирование с бинарным представлением)
фундаментальным (в моем понимании) называется тип, определение которого не опирается на существование и свойства других типов.
E>Псевдоним у тебя фундаментальный, а enum нет? E>Если вернуться к стандарту и его "встроенным" типам, то enum и указатель — встроенные...
псевдоним — это просто второе название одной и той же сущности (в данном случае типа).
__>>Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково.
E>Ну это фигня. Легко делается. Вот если ты ещё потребуешь, что бы если номер разнй, то будут вести по-разному, то будет хуже...
вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали
Здравствуйте, _hum_, Вы писали:
__>вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали
Ну делаешь mpl-массив из всех фундаментальных типов с их псевдонимами, и что бы узнать id типа просто ищешь его в этом массиве и его индекс и есть id. А если не нашёл, то тип не фундаментальный...
Ну это если в качестве PoC на бусте сваять, можно чуть компактнее, конечно, ту же идею реализовать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, tstalker, Вы писали:
T>Здравствуйте, _hum_, Вы писали:
__>>ага, а как же unsigned char и signed char, uint8_t, int8_t, short и прочие. вы уверены, что они все будут разные типы на всех платформах?
T>Уверен: T>
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
__>>вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали
E>Ну делаешь mpl-массив из всех фундаментальных типов с их псевдонимами, и что бы узнать id типа просто ищешь его в этом массиве и его индекс и есть id. А если не нашёл, то тип не фундаментальный...
E>Ну это если в качестве PoC на бусте сваять, можно чуть компактнее, конечно, ту же идею реализовать...
так на одной платформе будет одна система, на другой — другая (тот же uint64_t не всюду будет). и что? мне самому всеми этими техническими деталями заниматься? программисту просто должны предоcтавить средство работы —