Индекс по типу
От: x-code  
Дата: 28.03.16 07:44
Оценка:
Есть шаблонная функция, одна из перегрузок которой определена для простых типов — куда входит определенное фиксированное множество, скажем
int,unsigned int,char,unsigned char,short,unsigned short,long,unsigned long,foat,double и любые указатели.

 template<class T>
void foo(T & val, typename std::enable_if< is_simple_type<T>::value>::type* = 0 )
{
}

Для всех числовых типов необходимо внутри функции получить некий константный индекс, однозначно соответствующий типу T.
Для указателей пускай будет один индекс на всех (ну или никакого — то есть -1 или что-то такое).

Вопрос — как это сделать? Возможно как-то через boost::mpl, но как?
Re: Индекс по типу
От: jazzer Россия Skype: enerjazzer
Дата: 28.03.16 08:08
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Вопрос — как это сделать? Возможно как-то через boost::mpl, но как?


http://rsdn.ru/forum/cpp/2899831
Автор: jazzer
Дата: 02.04.08
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Индекс по типу
От: _Artem_ Россия  
Дата: 28.03.16 08:17
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Вопрос — как это сделать? Возможно как-то через boost::mpl, но как?


Например, можно так:

template <typename T>
static uint32_t hash()
{
    static const uint32_t index = ++last_added_;
    return index;
}
Re: Индекс по типу
От: Evgeny.Panasyuk Россия  
Дата: 28.03.16 08:28
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Вопрос — как это сделать? Возможно как-то через boost::mpl, но как?


http://www.boost.org/doc/libs/1_60_0/libs/mpl/doc/refmanual/find.html
// Example

typedef vector<char,int,unsigned,long,unsigned long> types;
typedef find<types,unsigned>::type iter;

BOOST_MPL_ASSERT(( is_same< deref<iter>::type, unsigned > ));
BOOST_MPL_ASSERT_RELATION( iter::pos::value, ==, 2 );
Re: Индекс по типу
От: Ops Россия  
Дата: 28.03.16 10:18
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Вопрос — как это сделать?


typeid(T).hash_code() не годится?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re: Индекс по типу
От: B0FEE664  
Дата: 29.03.16 10:40
Оценка:
Здравствуйте, x-code, Вы писали:

XC>
 template<class T>
XC>void foo(T & val, typename std::enable_if< is_simple_type<T>::value>::type* = 0 )
XC>{
XC>}

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;
}
И каждый день — без права на ошибку...
Re[2]: Индекс по типу
От: ajanov  
Дата: 30.03.16 19:09
Оценка:
Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, x-code, Вы писали:


XC>>Вопрос — как это сделать?


Ops>typeid(T).hash_code() не годится?


hash_code() не будет выдавать последовательных индексов, а также может возвращать одинаковые значения для двух разных типов
Re: Индекс по типу
От: T4r4sB Россия  
Дата: 30.03.16 19:22
Оценка:
Здравствуйте, x-code, Вы писали:

XC>скажем

XC>int,unsigned int,char,unsigned char,short,unsigned short,long,unsigned long,foat,double и любые указатели.
XC>Для указателей пускай будет один индекс на всех (ну или никакого — то есть -1 или что-то такое).

Ну можно переписать все простые типы вручную.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[3]: Индекс по типу
От: Ops Россия  
Дата: 30.03.16 20:00
Оценка:
Здравствуйте, ajanov, Вы писали:

A>hash_code() не будет выдавать последовательных индексов,

Не было в требованиях. Индекс — может быть индексом в мапе, например.
A>а также может возвращать одинаковые значения для двух разных типов
Только то, что касается cv.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[4]: Индекс по типу
От: watchmaker  
Дата: 31.03.16 00:03
Оценка:
Здравствуйте, Ops, Вы писали:

A>>а также может возвращать одинаковые значения для двух разных типов

Ops>Только то, что касается cv.
Конечно не только. Там используются алгоритмы не сложнее MurmurHash2. Коллизий — тьма. Вот пример подобрал: http://ideone.com/GL7Ngk
Конечно, для ограниченного множества типов можно проверить, что hash_code попарно не совпадают (например у типов signed и unsigned ), и если это так, то использовать этот метод. Но что программа должна будет делать, hash_code внезапно начнут совпадать? Использовать другой метод? Тогда лучше на него сразу и переключится.
Отредактировано 31.03.2016 0:21 watchmaker . Предыдущая версия .
Re[5]: Индекс по типу
От: Ops Россия  
Дата: 31.03.16 00:57
Оценка:
Здравствуйте, 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 внезапно начнут совпадать? Использовать другой метод? Тогда лучше на него сразу и переключится.


Ну печально это.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[6]: Индекс по типу
От: watchmaker  
Дата: 31.03.16 08:43
Оценка:
Здравствуйте, 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.


should != must.

Хеширования без коллизий никто не обещал.
Re[5]: Индекс по типу
От: BulatZiganshin  
Дата: 31.03.16 09:06
Оценка:
Здравствуйте, watchmaker, Вы писали:

W>Конечно не только. Там используются алгоритмы не сложнее MurmurHash2. Коллизий — тьма. Вот пример подобрал: http://ideone.com/GL7Ngk


тут дело не в алгоритме хеширования. 26^10 > 2^32. в целом, если у тебя 10+ тыщ типов, то вероятность коллизии будет достаточно велика
Люди, я люблю вас! Будьте бдительны!!!
Отредактировано 31.03.2016 9:06 BulatZiganshin . Предыдущая версия .
Re[6]: Индекс по типу
От: watchmaker  
Дата: 31.03.16 09:16
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:


BZ>тут дело не в алгоритме хеширования. 26^10 > 2^32.

Это да. Я криво написал. Не столь важно, какой конкретно из алгоритмов используется (MurmurHash или FNV-1a), а то что для этого используется независимое хеширование, а не альтернативный подход вроде этого
Автор: B0FEE664
Дата: 29.03.16
.

BZ>в целом, если у тебя 10+ тыщ типов, то вероятность коллизии будет достаточно велика

А могли бы и link-time PHF реализовать. Отсрочив появление коллизий на куда как более далёкие времена.
Re[7]: Индекс по типу
От: _hum_ Беларусь  
Дата: 31.03.16 10:20
Оценка:
Здравствуйте, 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 (вежливое предписание)?
Re[2]: Индекс по типу
От: _hum_ Беларусь  
Дата: 31.03.16 10:22
Оценка:
Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, x-code, Вы писали:


XC>>Вопрос — как это сделать?


Ops>typeid(T).hash_code() не годится?


Ops, а может, в знаете, в чем принцпипиальная трудность в языке ввести числовую идентификацию встроенных типов? зачем эти извращения с typeid-ами?
Re[7]: Индекс по типу
От: Ops Россия  
Дата: 31.03.16 11:47
Оценка:
Здравствуйте, watchmaker, Вы писали:

W>should != must.


Да, ты прав. http://www.ietf.org/rfc/rfc2119.txt
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[3]: Индекс по типу
От: Erop Россия  
Дата: 31.03.16 15:09
Оценка:
Здравствуйте, _hum_, Вы писали:

__>Ops, а может, в знаете, в чем принцпипиальная трудность в языке ввести числовую идентификацию встроенных типов? зачем эти извращения с typeid-ами?


Принцип раздельной компиляции мешает определять id типов до загрузки всех модулей...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: Индекс по типу
От: _hum_ Беларусь  
Дата: 31.03.16 15:37
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, _hum_, Вы писали:


__>>Ops, а может, в знаете, в чем принцпипиальная трудность в языке ввести числовую идентификацию встроенных типов? зачем эти извращения с typeid-ами?


E>Принцип раздельной компиляции мешает определять id типов до загрузки всех модулей...


Erop, я вас, по традиции, с первого раза не могу понять. я имел в виду, что мешает в стандарт ввести, что идентификатор uint8 — 0, uint16 — 1, float — 2 и т.п. и организовать compile-time type_trait<type>::uid?
Re[5]: Индекс по типу
От: Erop Россия  
Дата: 31.03.16 16:03
Оценка:
Здравствуйте, _hum_, Вы писали:

E>>Принцип раздельной компиляции мешает определять id типов до загрузки всех модулей...


__>Erop, я вас, по традиции, с первого раза не могу понять. я имел в виду, что мешает в стандарт ввести, что идентификатор uint8 — 0, uint16 — 1, float — 2 и т.п. и организовать compile-time type_trait<type>::uid?


А с std::vector<float> что делать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Индекс по типу
От: _hum_ Беларусь  
Дата: 31.03.16 16:10
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, _hum_, Вы писали:


E>>>Принцип раздельной компиляции мешает определять id типов до загрузки всех модулей...


__>>Erop, я вас, по традиции, с первого раза не могу понять. я имел в виду, что мешает в стандарт ввести, что идентификатор uint8 — 0, uint16 — 1, float — 2 и т.п. и организовать compile-time type_trait<type>::uid?


E>А с std::vector<float> что делать?


я вел речь, как и топикстартер, о встроенных простых типах.
Re[7]: Индекс по типу
От: BulatZiganshin  
Дата: 31.03.16 18:23
Оценка:
Здравствуйте, watchmaker, Вы писали:

BZ>>тут дело не в алгоритме хеширования. 26^10 > 2^32.

W>Это да. Я криво написал. Не столь важно, какой конкретно из алгоритмов используется (MurmurHash или FNV-1a), а то что для этого используется независимое хеширование, а не альтернативный подход вроде этого
Автор: B0FEE664
Дата: 29.03.16
.


BZ>>в целом, если у тебя 10+ тыщ типов, то вероятность коллизии будет достаточно велика

W>А могли бы и link-time PHF реализовать. Отсрочив появление коллизий на куда как более далёкие времена.

а с 128 битами вероятность коллизии будет меньше вероятности аппаратного сбоя при сравнении для справки, разные виды памяти имеют вероятность сбоя от 1e-10 до 1e-20
Люди, я люблю вас! Будьте бдительны!!!
Re[7]: Индекс по типу
От: Erop Россия  
Дата: 31.03.16 18:48
Оценка:
Здравствуйте, _hum_, Вы писали:

Это не особо надо, их же можно перечислить явно в тритсах каких-нибудь. Но не ясно зачем это надо...
Вот если бы можно было отражать любые типы, или любые типы из произвольного набора и т. д...

Ну и потом, указатель -- простой встроенный? Указатель на поле? И т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Отредактировано 31.03.2016 20:04 Erop . Предыдущая версия .
Re[8]: Индекс по типу
От: _hum_ Беларусь  
Дата: 01.04.16 08:03
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, _hum_, Вы писали:


E>Это не особо надо, их же можно перечислить явно в тритсах каких-нибудь. Но не ясно зачем это надо...


там же начнется головная боль с алиазами (считать uint8_t и char псевдонимами друг друга или нет?). да и зачем меня нагружать этой рутиной, когда могли бы в тайптрейтс (если это так просто) засунуть?
а нужно, например, для того, чтобы сократить код для динамического приведения типов (в том же union или arithmetic_variant)

E>Вот если бы можно было отражать любые типы, или любые типы из произвольного набора и т. д...


а это зачем? просто, имхо, значения сложных типов редко когда корректно приводятся друг к другу

E>Ну и потом, указатель -- простой встроенный? Указатель на поле? И т. д...


нет. простые (базовые, фундаментальные) — это те, которые не предполагают в своем определении задействования других типов.
Re[9]: Индекс по типу
От: Erop Россия  
Дата: 01.04.16 08:30
Оценка:
Здравствуйте, _hum_, Вы писали:

__>а нужно, например, для того, чтобы сократить код для динамического приведения типов (в том же union или arithmetic_variant)

А если мне надо ещё и своё длинное целое, рациональное или с фиксированной точкой добавить?
Это противоречит концепции С++, что библиотечные типы не хуже/лучше пользовательских...

__>а это зачем? просто, имхо, значения сложных типов редко когда корректно приводятся друг к другу

Ну указатели на них часто, например...
А ещё вот такая конструкция, как std::vector<int>& в std::vector<const int>& тебе?

__>нет. простые (базовые, фундаментальные) — это те, которые не предполагают в своем определении задействования других типов.


Ну это очень мало типов просто. Что делать с 64-битным целым, а со 128-битным, например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[10]: Индекс по типу
От: _hum_ Беларусь  
Дата: 01.04.16 10:03
Оценка:
Здравствуйте, 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-битным, например?


есть же вроде uint64_t
Re[11]: Индекс по типу
От: Erop Россия  
Дата: 01.04.16 10:16
Оценка:
Здравствуйте, _hum_, Вы писали:

__>насколько я себе представлял, вы можете только построить на основе уже существующих свои (наподобие, использовать class CFixedPointReal{uint16_t m_val; <набор операторов>}, чтобы организовать тип вещественных чисел с фиксированной точкой. но это уже будет не фундаментальный тип)


Вот, скажем, IntRange&lt;5, 65000&gt;
Автор: Erop
Дата: 29.04.08
в твоём понимании фундаментальный или нет?

__>разве часто? а можно пример?

Ну там база к потомку, брат к брату через dyn_cast и т. д...

E>>А ещё вот такая конструкция, как std::vector<int>& в std::vector<const int>& тебе?


__>в каком смысле? при чем здесь вектор?


Ну если хочу так привести, то что делать?

__>>>нет. простые (базовые, фундаментальные) — это те, которые не предполагают в своем определении задействования других типов.

Это оно:
enum FType { zerro, one, two };
?


__>есть же вроде uint64_t

Ну он же где-то есть, а где-то надо то, что ты называешь нефундаментальный писать...
Обычный С++-код такую операцию переносит легко...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Индекс по типу
От: _hum_ Беларусь  
Дата: 01.04.16 11:05
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, _hum_, Вы писали:


__>>насколько я себе представлял, вы можете только построить на основе уже существующих свои (наподобие, использовать class CFixedPointReal{uint16_t m_val; <набор операторов>}, чтобы организовать тип вещественных чисел с фиксированной точкой. но это уже будет не фундаментальный тип)


E>Вот, скажем, IntRange&lt;5, 65000&gt;
Автор: Erop
Дата: 29.04.08
в твоём понимании фундаментальный или нет?


конечно, нет, потому что его значения строятся на базе значений типа 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>Обычный С++-код такую операцию переносит легко...

речь не об этом, а о том, что есть кирпичики (фундаментальные типы), на базе которых можно построить все остальное.
и достаточно наделить эти кирпичики расширенными возможностями (как то идентификацией типов), чтобы это можно было протащить, при надобности, дальше.
Re[13]: Индекс по типу
От: Erop Россия  
Дата: 03.04.16 13:00
Оценка:
Здравствуйте, _hum_, Вы писали:

__>конечно, нет, потому что его значения строятся на базе значений типа int (вы не сможете определить этот тип без использования int)

Что значит "использования"?
Я могу сделать такой же нешаблонный, где нигде тип int использоваться не будет...

__>это только для объектов наследуемых классов. да и то, наверное, считается не лучшим кодом (для этого есть механизм виртуальных функций)


Это утверждение более чем спорное...

__>>>>>нет. простые (базовые, фундаментальные) — это те, которые не предполагают в своем определении задействования других типов.

E>>Это оно:
enum FType { zerro, one, two };
?


__>нет, не оно. enum использует подоснову int.

Этот не использует...

__>речь не об этом, а о том, что есть кирпичики (фундаментальные типы), на базе которых можно построить все остальное.

__>и достаточно наделить эти кирпичики расширенными возможностями (как то идентификацией типов), чтобы это можно было протащить, при надобности, дальше.

Не понятно, как тащить дальше совместимым образом. А без этого оно не особо надо.
Ну и нет проблем через трится "фунламентальным" типам ID назначить...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: Индекс по типу
От: tstalker Украина  
Дата: 04.04.16 07:24
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Для всех числовых типов необходимо внутри функции получить некий константный индекс, однозначно соответствующий типу T.


Может, не надо изобретать велосипед?
В STL есть кортеж.
В STL есть функция get().
Вот тебе готовый индекс типа:
#include <tuple>
#include <iostream>

int main(void)
{
    std::tuple<char, int, float> x { 'a', 12345, 3.14f };
    std::cout << std::get<0>(x) << std::endl;
    std::cout << std::get<1>(x) << std::endl;
    std::cout << std::get<2>(x) << std::endl;
}

a
12345
3.14

Можно даже воспользоваться именами типов:
#include <tuple>
#include <iostream>

int main(void)
{
    std::tuple<char, int, float> x { 'a', 12345, 3.14f };
    std::cout << std::get<char>(x) << std::endl;
    std::cout << std::get<int>(x) << std::endl;
    std::cout << std::get<float>(x) << std::endl;
}

a
12345
3.14
Re[14]: Индекс по типу
От: _hum_ Беларусь  
Дата: 05.04.16 13:29
Оценка:
Здравствуйте, 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 псевдонимами друг друга или нет?). да и зачем меня нагружать этой рутиной, когда могли бы в тайптрейтс (если это так просто) засунуть?

Re[2]: Индекс по типу
От: _hum_ Беларусь  
Дата: 05.04.16 13:33
Оценка:
Здравствуйте, tstalker, Вы писали:

T>Здравствуйте, x-code, Вы писали:


XC>>Для всех числовых типов необходимо внутри функции получить некий константный индекс, однозначно соответствующий типу T.


T>Может, не надо изобретать велосипед?

T>В STL есть кортеж.
T>В STL есть функция get().
T>Вот тебе готовый индекс типа:
T>
T>#include <tuple>
T>#include <iostream>

T>int main(void)
T>{
T>    std::tuple<char, int, float> x { 'a', 12345, 3.14f };
T>    std::cout << std::get<0>(x) << std::endl;
T>    std::cout << std::get<1>(x) << std::endl;
T>    std::cout << std::get<2>(x) << std::endl;
T>}
T>

T>a
T>12345
T>3.14

ага, а как же unsigned char и signed char, uint8_t, int8_t, short и прочие. вы уверены, что они все будут разные типы на всех платформах?
Re[15]: Индекс по типу
От: Erop Россия  
Дата: 05.04.16 18:51
Оценка:
Здравствуйте, _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...
Люди кторую из системов просят перенумеровать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[16]: Индекс по типу
От: _hum_ Беларусь  
Дата: 06.04.16 07:54
Оценка:
Здравствуйте, 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>Люди кторую из системов просят перенумеровать?

Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково.
Re[17]: Индекс по типу
От: Erop Россия  
Дата: 06.04.16 08:11
Оценка:
Здравствуйте, _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 и указатель — встроенные...

__>Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково.


Ну это фигня. Легко делается. Вот если ты ещё потребуешь, что бы если номер разнй, то будут вести по-разному, то будет хуже...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: Индекс по типу
От: tstalker Украина  
Дата: 07.04.16 08:39
Оценка: :)
Здравствуйте, _hum_, Вы писали:

__>ага, а как же unsigned char и signed char, uint8_t, int8_t, short и прочие. вы уверены, что они все будут разные типы на всех платформах?


Уверен:
#include <tuple>
#include <string>
#include <cstdint>
#include <iostream>

int main(void)
{
    using namespace std;
    tuple<int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t,
        bool, signed char, unsigned char, signed short, unsigned short, signed int, unsigned int,
        signed long, unsigned long, signed long long, unsigned long long, string> x
    { 'a', 'b', 3, 4, 5, 6, 7, 8, true, 'c', 'd', 12, 13u, 14, 15u, 16l, 17ul, 18ll, 19ull, "abcde"s };
    cout << get<0>(x) << ' ' << get<1>(x) << ' ' << get<2>(x) << ' ' << get<3>(x) << ' '
        << get<4>(x) << ' ' << get<5>(x) << ' ' << get<6>(x) << ' ' << get<7>(x) << ' '
        << get<8>(x) << ' ' << get<9>(x) << ' ' << get<10>(x) << ' ' << get<11>(x) << ' '
        << get<12>(x) << ' ' << get<13>(x) << ' ' << get<14>(x) << ' ' << get<15>(x) << ' '
        << get<16>(x) << ' ' << get<17>(x) << ' ' << get<18>(x) << ' ' << get<19>(x) << endl;
}


a b 3 4 5 6 7 8 1 c d 12 13 14 15 16 17 18 19 abcde
Отредактировано 07.04.2016 9:01 tstalker . Предыдущая версия .
Re[18]: Индекс по типу
От: _hum_ Беларусь  
Дата: 07.04.16 10:10
Оценка: +1
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, _hum_, Вы писали:


E>>>Да, это тип для работы с числами, такой же как short, наример. Чем он менее "фундаментальный" чем short?


__>>Если речь про enum, то я уже выше дал определение фундаментальности — независимость определения типа от других типов. Enum заивисит, а значит, не является фундаментальным.


E>Так чем short более фундаментален, чем
enum { start = 0, end = 10000 };
?

E>И то и то поддерживается процессором, и то и то числа, поддиапазон int, и то и то занимает 2 байта...

см. ниже определение типа и фундаментальности. а вообще, en.cppreference.com/w/cpp/language/type


__>>Это не поможет. Проблема-то именно в многообразии типов и не совсем прозрачной их операционной семантике (тот же 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>Ну это фигня. Легко делается. Вот если ты ещё потребуешь, что бы если номер разнй, то будут вести по-разному, то будет хуже...


вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали
Re[19]: Индекс по типу
От: Erop Россия  
Дата: 07.04.16 10:25
Оценка:
Здравствуйте, _hum_, Вы писали:

__>вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали


Ну делаешь mpl-массив из всех фундаментальных типов с их псевдонимами, и что бы узнать id типа просто ищешь его в этом массиве и его индекс и есть id. А если не нашёл, то тип не фундаментальный...

Ну это если в качестве PoC на бусте сваять, можно чуть компактнее, конечно, ту же идею реализовать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: Индекс по типу
От: _hum_ Беларусь  
Дата: 07.04.16 10:30
Оценка:
Здравствуйте, tstalker, Вы писали:

T>Здравствуйте, _hum_, Вы писали:


__>>ага, а как же unsigned char и signed char, uint8_t, int8_t, short и прочие. вы уверены, что они все будут разные типы на всех платформах?


T>Уверен:

T>
T>#include <tuple>
T>#include <string>
T>#include <cstdint>
T>#include <iostream>

T>int main(void)
T>{
T>    using namespace std;
T>    tuple<int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t,
T>        bool, signed char, unsigned char, signed short, unsigned short, signed int, unsigned int,
T>        signed long, unsigned long, signed long long, unsigned long long, string> x
T>    { 'a', 'b', 3, 4, 5, 6, 7, 8, true, 'c', 'd', 12, 13u, 14, 15u, 16l, 17ul, 18ll, 19ull, "abcde"s };
T>    cout << get<0>(x) << ' ' << get<1>(x) << ' ' << get<2>(x) << ' ' << get<3>(x) << ' '
T>        << get<4>(x) << ' ' << get<5>(x) << ' ' << get<6>(x) << ' ' << get<7>(x) << ' '
T>        << get<8>(x) << ' ' << get<9>(x) << ' ' << get<10>(x) << ' ' << get<11>(x) << ' '
T>        << get<12>(x) << ' ' << get<13>(x) << ' ' << get<14>(x) << ' ' << get<15>(x) << ' '
T>        << get<16>(x) << ' ' << get<17>(x) << ' ' << get<18>(x) << ' ' << get<19>(x) << endl;
T>}
T>


T>a b 3 4 5 6 7 8 1 c d 12 13 14 15 16 17 18 19 abcde


cplusplus.com/reference/cstdint
<cstdint> (stdint.h)
Types
The following are typedefs of fundamental integral types or extended integral types.

Re[20]: Индекс по типу
От: _hum_ Беларусь  
Дата: 07.04.16 12:11
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, _hum_, Вы писали:


__>>вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали


E>Ну делаешь mpl-массив из всех фундаментальных типов с их псевдонимами, и что бы узнать id типа просто ищешь его в этом массиве и его индекс и есть id. А если не нашёл, то тип не фундаментальный...


E>Ну это если в качестве PoC на бусте сваять, можно чуть компактнее, конечно, ту же идею реализовать...


так на одной платформе будет одна система, на другой — другая (тот же uint64_t не всюду будет). и что? мне самому всеми этими техническими деталями заниматься? программисту просто должны предоcтавить средство работы —
get_fundamental_type_id(type)

и
cast_to_fundamental_type(fundamental_type_id, val)
Re[19]: Индекс по типу
От: B0FEE664  
Дата: 07.04.16 12:34
Оценка:
Здравствуйте, _hum_, Вы писали:

__>>>Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково.

__>вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали

Набросок давно лежит рядом
Автор: B0FEE664
Дата: 29.03.16


проверка здесь
И каждый день — без права на ошибку...
Re[20]: Индекс по типу
От: _hum_ Беларусь  
Дата: 07.04.16 13:08
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, _hum_, Вы писали:


__>>>>Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково.

__>>вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали

BFE>Набросок давно лежит рядом
Автор: B0FEE664
Дата: 29.03.16


BFE>проверка здесь


да, прием интересный, но все равно еще же и морока с реализацией
cast_to_fundamental_type(fundamental_type_id, val)

будет.
Отредактировано 07.04.2016 13:15 _hum_ . Предыдущая версия .
Re[21]: Индекс по типу
От: B0FEE664  
Дата: 07.04.16 14:26
Оценка: +1
Здравствуйте, _hum_, Вы писали:

__>>>>>Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково.

__>>>вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали

BFE>>Набросок давно лежит рядом
Автор: B0FEE664
Дата: 29.03.16

BFE>>проверка здесь

__>да, прием интересный, но все равно еще же и морока с реализацией

__>
__>cast_to_fundamental_type(fundamental_type_id, val)
__>

__>будет.

Вы уж определитесь с набором операций и требований, а то складывается впечатление, что вы сами не знаете, чего вам надо:

#include <iostream>

template<int id> 
struct IdToType
{
    typedef void type;
    static const int s_nTypeId = -1;
};


template<class T> 
struct TypeToId
{
    typedef T type;
    static const int s_nTypeId = -1;
};


template<> struct IdToType<1>    {typedef int   type; static const int s_nTypeId = 1;};
template<> struct TypeToId<int>  {typedef int   type; static const int s_nTypeId = 1;};
                                                
template<> struct IdToType<2>    {typedef char  type; static const int s_nTypeId = 2;};
template<> struct TypeToId<char> {typedef char  type; static const int s_nTypeId = 2;};
                                 
template<> struct IdToType<3>    {typedef short type; static const int s_nTypeId = 3;};
template<> struct TypeToId<short>{typedef short type; static const int s_nTypeId = 3;};

template<> struct IdToType<4>    {typedef float type; static const int s_nTypeId = 4;};
template<> struct TypeToId<float>{typedef float type; static const int s_nTypeId = 4;};


int main(int argc, char* argv[])
{
    std::cout << "id of int = "   << TypeToId<int>::s_nTypeId   << std::endl;
    std::cout << "id of float = " << TypeToId<float>::s_nTypeId << std::endl;

    float f = 97.234f;
    IdToType<1>::type n = static_cast<IdToType<1>::type>(f);

    std::cout << "n = " << n << std::endl;

    auto ch = static_cast<IdToType<TypeToId<char>::s_nTypeId>::type>(f);
    std::cout << "ch = " << ch << std::endl;

    return 0;
}



id of int = 1
id of float = 4
n = 97
ch = a
И каждый день — без права на ошибку...
Re[21]: Индекс по типу
От: Erop Россия  
Дата: 07.04.16 15:03
Оценка:
Здравствуйте, _hum_, Вы писали:

__>так на одной платформе будет одна система, на другой — другая (тот же uint64_t не всюду будет). и что? мне самому всеми этими техническими деталями заниматься? программисту просто должны предоcтавить средство работы —



Ну так и будет примерно
fundamental_type_to_id<uint64t>::id;
fundamental_id_to_type<15>::type;


только с uint64_t проблемка будет. Он не всегда есть, так что твой код с таким типом будет непереносимый. В библиотеке-то можно условную компиляцию намутить, а вот что в клиентском коде делать?

Ну и не ясно, должны ли в перечислении участвовать фундаментальные нестандартные типы, ну __m128 например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: Индекс по типу
От: _hum_ Беларусь  
Дата: 07.04.16 15:07
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, _hum_, Вы писали:


__>>>>>>Люди хотят, чтобы перенумерованы были типы, которые отличаются операционной семантикой. Людям все равно, как называется тип, главное уверенность, что если номер одинаковый, то типы будут всюду в коде вести себя одинаково.

__>>>>вот вы все говорите "легко" и "фигня", а так ни разу еще даже набросок решения не показали

BFE>>>Набросок давно лежит рядом
Автор: B0FEE664
Дата: 29.03.16

BFE>>>проверка здесь

__>>да, прием интересный, но все равно еще же и морока с реализацией

__>>
__>>cast_to_fundamental_type(fundamental_type_id, val)
__>>

__>>будет.

BFE>Вы уж определитесь с набором операций и требований, а то складывается впечатление, что вы сами не знаете, чего вам надо:


ладно, может, вы и правы.

п.с. все же речь шла про динамическое приведение типов (в процессе работы программы),а не статическое
Re[22]: Индекс по типу
От: _hum_ Беларусь  
Дата: 07.04.16 15:17
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, _hum_, Вы писали:


__>>так на одной платформе будет одна система, на другой — другая (тот же uint64_t не всюду будет). и что? мне самому всеми этими техническими деталями заниматься? программисту просто должны предоcтавить средство работы —



E>Ну так и будет примерно
fundamental_type_to_id<uint64t>::id;
E>fundamental_id_to_type<15>::type;


речь шла про что-то наподобие cast_to_fundamental_type(id, buffer), где buffer — просто байтовый буффер. например, для организации
class Variant
{
  int m_type_id;
  char m_buff[8];

public:
  //------------------------
  Variant():m_type_id(-1){}
  //------------------------
  template<typename T>
  void setVal(T val)
  {
     m_type_id = get_fundamental_type_id<T>();
     *reinterpret_cast<T*>(m_Buffer) = val;
  }
  //------------------------
  template<typename T>
  bool is(void)const
  {
     return get_fundamental_type_id<T>() == m_type_id;
  }
  //------------------------
  template<typename T>
  T get_casted_val()
  {
     return cast_to_fundamental_type(m_type_id, m_buff);
  }
  //------------------------
}


но, прикинув, я понял, что смысла в таком особого нет..
Re[23]: Индекс по типу
От: Erop Россия  
Дата: 07.04.16 15:48
Оценка:
Здравствуйте, _hum_, Вы писали:

__>но, прикинув, я понял, что смысла в таком особого нет..


+100500
Это главная проблема этой идеи. Оно не надо
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[23]: Индекс по типу
От: Erop Россия  
Дата: 07.04.16 16:15
Оценка:
Здравствуйте, _hum_, Вы писали:

__>п.с. все же речь шла про динамическое приведение типов (в процессе работы программы),а не статическое


А как в С++ вернуть значение приведённое к типу, определённому динамически?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.