Есть шаблонная функция, одна из перегрузок которой определена для простых типов — куда входит определенное фиксированное множество, скажем
int,unsigned int,char,unsigned char,short,unsigned short,long,unsigned long,foat,double и любые указатели.
Для всех числовых типов необходимо внутри функции получить некий константный индекс, однозначно соответствующий типу T.
Для указателей пускай будет один индекс на всех (ну или никакого — то есть -1 или что-то такое).
Вопрос — как это сделать? Возможно как-то через boost::mpl, но как?
XC>Для всех числовых типов необходимо внутри функции получить некий константный индекс, однозначно соответствующий типу T. XC>Для указателей пускай будет один индекс на всех (ну или никакого — то есть -1 или что-то такое).
Не уверен, что нужен boost, всё и так просто и прозрачно:
#include <iostream>
#include <type_traits>
int GetId()
{
static int id = 0;
id++;
return id;
}
template <class T>
struct TypeId
{
typedef T type;
static const int id;
};
template <class T>
struct TypeId<T*>
{
typedef T* type;
static const int id = -1;
};
//static template <class T>
const int TypeId<T>::id = GetId();
class A
{
};
class B
{
};
class C
{
public:
C()
{
std::cout << "id of this for C = " << TypeId<std::remove_pointer<decltype(this)>::type>::id << std::endl;
}
};
template<class T>
void foo(T & val)
{
std::cout << "foo, id of T = " << TypeId<T>::id << std::endl;
}
int main(int argc, char* argv[])
{
int n = 0;
foo(n);
int* pn = &n;
foo(pn);
char ch = 'a';
foo(ch);
char* pch = &ch;
foo(pch);
std::cout << "id of A = " << TypeId<A>::id << std::endl;
std::cout << "id of C = " << TypeId<C>::id << std::endl;
std::cout << "id of A = " << TypeId<A>::id << std::endl;
std::cout << "id of B = " << TypeId<B>::id << std::endl;
std::cout << "id of C = " << TypeId<C>::id << std::endl;
std::cout << "id of int = " << TypeId<int>::id << std::endl;
std::cout << "id of int* = " << TypeId<int*>::id << std::endl;
std::cout << "id of A* = " << TypeId<A*>::id << std::endl;
return 0;
}
Здравствуйте, x-code, Вы писали:
XC>скажем XC>int,unsigned int,char,unsigned char,short,unsigned short,long,unsigned long,foat,double и любые указатели. XC>Для указателей пускай будет один индекс на всех (ну или никакого — то есть -1 или что-то такое).
Ну можно переписать все простые типы вручную.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, ajanov, Вы писали:
A>hash_code() не будет выдавать последовательных индексов,
Не было в требованиях. Индекс — может быть индексом в мапе, например. A>а также может возвращать одинаковые значения для двух разных типов
Только то, что касается cv.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
A>>а также может возвращать одинаковые значения для двух разных типов Ops>Только то, что касается cv.
Конечно не только. Там используются алгоритмы не сложнее MurmurHash2. Коллизий — тьма. Вот пример подобрал: http://ideone.com/GL7Ngk
Конечно, для ограниченного множества типов можно проверить, что hash_code попарно не совпадают (например у типов signed и unsigned ), и если это так, то использовать этот метод. Но что программа должна будет делать, hash_code внезапно начнут совпадать? Использовать другой метод? Тогда лучше на него сразу и переключится.
Здравствуйте, watchmaker, Вы писали:
W>Конечно не только. Там используются алгоритмы не сложнее MurmurHash2. Коллизий — тьма. Вот пример подобрал: http://ideone.com/GL7Ngk
У меня под рукой только какой-то драфт, судя по нему, это несоответствие стандарту (18.7.1-8):
Remark: an implementation should return different values for two type_info objects which do not compare equal.
W>Конечно, для ограниченного множества типов можно проверить, что hash_code попарно не совпадают (например у типов signed и unsigned ), и если это так, то использовать этот метод. Но что программа должна будет делать, hash_code внезапно начнут совпадать? Использовать другой метод? Тогда лучше на него сразу и переключится.
Ну печально это.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, watchmaker, Вы писали:
W>Конечно не только. Там используются алгоритмы не сложнее MurmurHash2. Коллизий — тьма. Вот пример подобрал: http://ideone.com/GL7Ngk
тут дело не в алгоритме хеширования. 26^10 > 2^32. в целом, если у тебя 10+ тыщ типов, то вероятность коллизии будет достаточно велика
BZ>тут дело не в алгоритме хеширования. 26^10 > 2^32.
Это да. Я криво написал. Не столь важно, какой конкретно из алгоритмов используется (MurmurHash или FNV-1a), а то что для этого используется независимое хеширование, а не альтернативный подход вроде этого
.
BZ>в целом, если у тебя 10+ тыщ типов, то вероятность коллизии будет достаточно велика
А могли бы и link-time PHF реализовать. Отсрочив появление коллизий на куда как более далёкие времена.
Здравствуйте, watchmaker, Вы писали:
W>Здравствуйте, Ops, Вы писали:
Ops>>У меня под рукой только какой-то драфт, судя по нему, это несоответствие стандарту (18.7.1-8): Ops>>
Ops>>Remark: an implementation should return different values for two type_info objects which do not compare equal.
W>should != must.
разве? разве не все стандарты пишутся через should (вежливое предписание)?
Здравствуйте, _hum_, Вы писали:
__>Ops, а может, в знаете, в чем принцпипиальная трудность в языке ввести числовую идентификацию встроенных типов? зачем эти извращения с typeid-ами?
Принцип раздельной компиляции мешает определять id типов до загрузки всех модулей...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
__>>Ops, а может, в знаете, в чем принцпипиальная трудность в языке ввести числовую идентификацию встроенных типов? зачем эти извращения с typeid-ами?
E>Принцип раздельной компиляции мешает определять id типов до загрузки всех модулей...
Erop, я вас, по традиции, с первого раза не могу понять. я имел в виду, что мешает в стандарт ввести, что идентификатор uint8 — 0, uint16 — 1, float — 2 и т.п. и организовать compile-time type_trait<type>::uid?
Здравствуйте, _hum_, Вы писали:
E>>Принцип раздельной компиляции мешает определять id типов до загрузки всех модулей...
__>Erop, я вас, по традиции, с первого раза не могу понять. я имел в виду, что мешает в стандарт ввести, что идентификатор uint8 — 0, uint16 — 1, float — 2 и т.п. и организовать compile-time type_trait<type>::uid?
А с std::vector<float> что делать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, 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тавить средство работы —
Здравствуйте, _hum_, Вы писали:
__>>>Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково. __>вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, _hum_, Вы писали:
__>>>>Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково. __>>вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали
BFE>Набросок давно лежит рядом
Здравствуйте, _hum_, Вы писали:
__>>>>>Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково. __>>>вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали
BFE>>Набросок давно лежит рядом
Здравствуйте, _hum_, Вы писали:
__>так на одной платформе будет одна система, на другой — другая (тот же uint64_t не всюду будет). и что? мне самому всеми этими техническими деталями заниматься? программисту просто должны предоcтавить средство работы —
только с uint64_t проблемка будет. Он не всегда есть, так что твой код с таким типом будет непереносимый. В библиотеке-то можно условную компиляцию намутить, а вот что в клиентском коде делать?
Ну и не ясно, должны ли в перечислении участвовать фундаментальные нестандартные типы, ну __m128 например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, _hum_, Вы писали:
__>>>>>>Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково. __>>>>вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали
BFE>>>Набросок давно лежит рядом
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
__>>так на одной платформе будет одна система, на другой — другая (тот же uint64_t не всюду будет). и что? мне самому всеми этими техническими деталями заниматься? программисту просто должны предоcтавить средство работы —
Здравствуйте, _hum_, Вы писали:
__>но, прикинув, я понял, что смысла в таком особого нет..
+100500
Это главная проблема этой идеи. Оно не надо
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, _hum_, Вы писали:
__>п.с. все же речь шла про динамическое приведение типов (в процессе работы программы),а не статическое
А как в С++ вернуть значение приведённое к типу, определённому динамически?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском