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

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

__>>Зачем нужно писать & и * если можно без них.
G>Можно. Смарт-пойнтеры и фабрики в помощь.
Без ссылок там все равно не обойтись.
__>>Почему нельзя определить семантику передачи аргументов ?
G>Гм... ее из сигнатуры функции почти всегда видно. Разве нет? отрабатывайте стиль.
void f(int& i);
Это out или in-out аргумент ?
Без документации нельзя узнать.
__>>Почему нужно делать разного рода извращения, чтобы работать с примитивными типами ?
G>Ну у каждого свои склонности. Кто то только через извращения проблемы решать может.
А как вы решаете эти проблемы:

template<typename T>
size_t f(T const& t)
{
 return t.size();
}

f(1); // не работает.

Обход:

template<bool primitive>
struct f_impl
{
 template<typename T>
 static void f(T const& t)
 {
  return sizeof(t);
 }
};

template<>
struct f_impl<false>
{
 template<typename T>
 static void f(T const& t)
 {
  return t.size();
 }
};

template<typename T>
size_t f(T const& t)
{
 return f_impl<is_primitive<T>::value>::f(t);

f(1); // теперь работает

А можно ведь было:

size_t f(object& t)
{
 return t.size();
}

__>>Почему нельзя написать код так, чтобы он работал для всего ?
G>Угу, в отдельно взятых 2 тысячах строк кода. Для того, чтобы ваш подход работал для всех, он должен стать стандартом. А предпосылок для этого в мотивации как то маловато. Скажу более — эта библиотека будет даже вредна для неокрепших умов.
А мне кажется наоборот.
Намного проще знать, что все типы это классы, чем вспоминать, что иногда есть примитвные типы, которые нужно передавать по значению, а не по ссылке.
__>>Из-за того, что небыло представленно решение этих и других проблем придумали обходные решения, вместо того, чтобы решить саму проблему.
G>Полноте... я вот о такой проблеме до вчерашнего вечера и не подозревал. В чем проблема то?
Смотрите выше.