Западло

[psilogic]

[ Предупреждение: для непрограммистов неинтересно ]

Пусть у нас есть два класса - базовый Base и отнаследованный от него Derived. В Derived есть конструктор, похожий на конструктор копии с параметром типа Base.

class Base
{
...
};

class Derived: public Base
{
public:
    Derived() {...}
    Derived(const Base &b) { /* важные манипуляции */ }
};

Допустим, в программе это используется вот так:

Derived d1;
Derived d2(d1);

И оно не работает.

Тщательное расследование показало эпическое западло...



В какой-то момент я внес часть кода в функцию:

void foo(Base &d1)
{
    Derived d2(d1);
    ...
}
...
Derived d1;
foo(d1);

И вдруг оно начало работать! Счастливый, я все так и оставил, предполагая разобраться как-нибудь потом. Сегодня это как-нибудь наступило.

Западло состоит в том, что в строке Derived d2(d1) не всегда вызывается второй конструктор и не будут выполняться "важные манипуляции". Вместо этого будет вызван "невидимый" автоматически сгенерированный конструктор-копии, и все поля будут тупо скопированы из d1 в d2.

Это происходит в том случае, если d1 имеет тип Derived. Если Base - то все хорошо. Вот почему та функция исправляла проблему. Так тоже будет работать:

Derived d2((Base&)d1);

Лечится это легко:

class Base
{
...
};

class Derived: public Base
{
public:
    Derived() {...}
    Derived(const Base &b) { /* важные манипуляции */ }
    Derived(const Derived &b) { /* важные манипуляции */ }
};

Но ведь и вляпаться тоже легко...

Comments

[ab83.livejournal.com]

Извините, что встреваю, а нельзя ли про вредность вот этого
"Использование const вместо #define для числовых констант"
чуть подробнее.

А то мне предстоит программу на с++ делать, а опыта мало,
тот, что был, почти выветрился.

[psilogic.livejournal.com]

Использование const вместо #define соответсвует чисто идеологическому переходу с парадигмы C на C++. Соответственно везде, где пропагандируется идеология C++, пропагандирутся и const вместо #define. Проблема в том, что это чисто идеологическая, пропагандистская фишка. Ее назначение - разного рода холивары и пособия типа "C++ за два дня для ламеров".

Для ламера надо вызубрить некое правило, как можно более простое и бездумное. Например, "препроцессор - плохо, const - хорошо". Без всяких оговорок типа, когда, где и при каких условиях. Если же подходить с практических позиций, то лучше далеко не всегда и не везде. Но это надо чуть-чуть мозги включать и вникать.

Конкретно в отношении const.

1. Для автоматических переменных получается переменная, ограниченная по области видимости. Это бонус, отмечаем его как "+1". Плата за это небольшая - чуть больше писать:

#define MAX_CHANNEL 2
и
const int MAX_CHANNEL = 2;

Поскольку писать надо больше совсем чуть-чуть, можно отметить это не как "-1", а, скажем, "-0.5". Итого: +1 против -0.5. Вывод - для автоматических переменных const немного лучше.

2. Для глобальных переменных у const пропадает бонус ограниченной области видимости. Зато может появиться другой бонус: в отладчике видно ее значение, а значение #define не видно. Но это зависит от отладчика. Иной отладчик и #define видит. Так что получается "+0.5". Далее, начинаются несовместимости между C и C++, разные тонкости с версиями компиляторов. Но это тоже редкое явление, так что тоже "-0.5". И еще "-0.5" за то, что длинее.

Итого: +0.5 против -1. Вывод - для глобальных переменных const немного хуже.

3. Если числовая константа - член класса, то для корректного оформления в виде const придется вносить правку и в хэдер, и в исходник, количество писанины растет:

.h:
static const int MAX_CHANNEL = 2;
.cpp:
const int ClassName::MAX_CHANNEL;

Это уже -1. При написании кода появляется необходимость переключаться между файлами. Еще -1. За одно и то же время можно написать константу через const, либо константу через #define плюс комментарий к ней.

Итого: +1 против -2. Вывод - для констант класса const уже намного хуже.

Но самое прикольное то, что есть enum, который лучше, чем #define и лучше, чем const в случаях 2 и 3. Он и показывается в отладчике, и позволяет ограничивать область видимости классом, и не требует залезать в .cpp, и писанины не больше:
enum { MAX_CHANNEL = 2 };

Но enum - "не идеологичен". ;)

Вывод не для ламеров: для автоматических констант юзать const, для глобальных констант (в том числе констант класса) юзать enum.

[alisarin.livejournal.com]

Не понимаю о чем это, но смеюсь над тем _как_это_ :))

[psilogic.livejournal.com]

Интересно, что именно показалось зобавным? :)

[alisarin.livejournal.com]

Конструкции (или типы данных - не знаю, может и то, и другое) в разных случаях сопровождаются разными ограничениями, то бишь универсальность не обеспечена :)

[psilogic.livejournal.com]

Иногда ограничения - это очень полезно. Скажем, некая величина обозначается словом size и обозначает размер. Но в программе может быть тыща разных размеров. Удобно все их называть size, но чтобы при этом изменение одного size не влияло на изменение другого. Так что каждый size имеет как бы "область применимости", которая ограничена.

[alisarin.livejournal.com]

Я, грешным делом, думал, что такое появляется под влиянием английской фонетики: начальный звук "civil" и "concrete" очень непохож, а буква "c" - одна и та же :)

Когда же тип состоит из подтипов, и последние используются, но как подтипы не определяются, ... хозяин - барин :))

[psilogic.livejournal.com]

Такое появляется под влиянием многозначности естественного языка. Слово "стол" может означать самые разные столы в зависимости от контекста.

[bsivko.livejournal.com]

1. Для автоматических переменных получается переменная, ограниченная по области видимости. Это бонус, отмечаем его как "+1". Плата за это небольшая - чуть больше писать:

#define MAX_CHANNEL 2
и
const int MAX_CHANNEL = 2;

Поскольку писать надо больше совсем чуть-чуть, можно отметить это не как "-1", а, скажем, "-0.5". Итого: +1 против -0.5. Вывод - для автоматических переменных const немного лучше.
------
Писать больше только для типизации. Если она нужна (а она часто именно нужна, хотя обезьяне с гранатой она обычно не нужна; а в макросах возможности типизации(отобрать гранату) нет).
Если программист привык писать наобум, то держи достойную замену:
const MAX_CHANNEL = 2; // без int, все работает

Ограничение области видимости - это возможность. При желании const можно засунуть в namespace, define же лишены этой привилегии и могут разнести в пух и прах кучу любого подключенного кода, и хорошо если это компилятор заметит. const'ы же избавляют от множества потенциальных ошибок данного рода, за что им в данной шкале +10. Обычно это понимают только после наступленияы
------------

2. Для глобальных переменных у const пропадает бонус ограниченной области видимости.
------------
Глобальное пространство имен лучше вообще не засорять. За всю историю использования плюсов в боевых проектах мне приходилось использовать глобальные константы только в единичных случаях пару раз.

------------
3. Если числовая константа - член класса, то для корректного оформления в виде const придется вносить правку и в хэдер, и в исходник, количество писанины растет:

.h:
static const int MAX_CHANNEL = 2;
.cpp:
const int ClassName::MAX_CHANNEL;

Это уже -1. При написании кода появляется необходимость переключаться между файлами. Еще -1. За одно и то же время можно написать константу через const, либо константу через #define плюс комментарий к ней.

Итого: +1 против -2. Вывод - для констант класса const уже намного хуже.
--------------
Тут вообще глупость написана. Потому что define не может быть членом класса. Потому он не имеет никакого преимущества. Возможность прописать const в класс является дополнительной возможностью, которую можно использовать по своему усмотрению, что несомненно '+'.

--------------
В свое время мой вывод не для ламеров - везде где можно заменить константу define на const - нужно это делать, и при этом провести типизацию.
define же использовать для хитрожопых конструкций замены, экзотических случаев или случаев, когда этого требует комплиятор/библиотека или ещё кто.

[bsivko.livejournal.com]

*Обычно это понимают только после наступленияы

недописано (;

после наступления на грабли и очухивания и обхода их в течении часов или даже дней глубокой отладки.

[psilogic.livejournal.com]

[ Писать больше только для типизации. ]

Вот это как раз - "достойный" пример бездумного следования религиозной заповеди: "типизация - это хорошо" - всегда, независимо ни от чего. А теперь просвети меня, как и почему в данном конкретном случае типизация - это хорошо? Не в параметрах функций, а вот конкретно для констант. Слабо обосновать? Ну и для закрепления пройденного, подумай: что, у констант типов нет? Суффиксы L, U, F не для эстетов? :)

[ Ограничение области видимости - это возможность. ]

Ты вообще читаешь то, что комментируешь? Я отметил, что "это бонус" - какие претензии, не понимаю.

[ за что им в данной шкале +10 ]

А вот это - уже религиозно-идеологическое воззрение. Для холиваров - прекрасно, для серьезного рассмотрения - негодно. Может, сразу +1000^1000? :) Ну чиста патаму шта эта крута!? :)

[ Потому что define не может быть членом класса. ]

Следи за руками:
#define ClassName__MAX_CHANNEL = 2;
:)

Ну и про enum не забудь, он все равно лучше.

[bsivko.livejournal.com]

[ Писать больше только для типизации. ]

Вот это как раз - "достойный" пример бездумного следования религиозной заповеди: "типизация - это хорошо" - всегда, независимо ни от чего. А теперь просвети меня, как и почему в данном конкретном случае типизация - это хорошо? Не в параметрах функций, а вот конкретно для констант. Слабо обосновать? Ну и для закрепления пройденного, подумай: что, у констант типов нет? Суффиксы L, U, F не для эстетов? :)
----------------
Сарказм неуместен. Ты не с ламером разговариваешь.

Итак, что напишет программа в такой реализации:

#include

const CH = '0';

int main(int argc, char* argv[])
{
std::cout << CH << std::endl;
return 0;
}

?

Без компиляции и запуска ответишь?

И что измениться при проведении замены на
const char CH = '0';
?

------------------------

[ за что им в данной шкале +10 ]

А вот это - уже религиозно-идеологическое воззрение. Для холиваров - прекрасно, для серьезного рассмотрения - негодно. Может, сразу +1000^1000? :) Ну чиста патаму шта эта крута!? :)
------------------------
Потому что решение проблемы потенцильной ошибки, на вылавливание которой можно потрать куеву хучу времени намного важнее (в данном случае на порядок) четырех-пяти символов.

Ход мысли ответа понятен?
------------------------
[ Потому что define не может быть членом класса. ]

Следи за руками:
#define ClassName__MAX_CHANNEL = 2;
:)
------------------------
Это уже грязный хак. Манипуляторы отрывать надо за такое.

[bsivko.livejournal.com]

iostream поцкуды, выкусили... (;

[psilogic.livejournal.com]

[ Сарказм неуместен. Ты не с ламером разговариваешь. ]

гы гы гы - сраказм ему мой не понравился видите ли :) за собой то не замечаем, да? :)

[ Без компиляции и запуска ответишь? ]

Отвечу - либо компилятор напишет ошибку (если компилятор не допускает тип int по-умолчанию), либо 48 (ASCII-код символа нуля). А зачем ты такую муру написал? Это не техника #define и некорректная техника для const. Ты пытаешься мне показать, что мура - это мура? Так я соглашусь: мура. :)

[ И что измениться при проведении замены на '0' ]

'0' будет.

А теперь берем технику с #define:

#define CH '0'

Константа типа char, напечатает, опять же, '0'. Ну и где оно - счастье? :)

[ Потому что решение проблемы потенцильной ошибки, на вылавливание которой можно потрать куеву хучу времени намного важнее (в данном случае на порядок) четырех-пяти символов. ]

Это ты какой случай рассматриваешь? Константа-член-класса? Тогда не четырех-пяти, а придется переключаться на файл-исходник и там эту переменную еще и определять. А, если файла-исходника нет, то создавать его, вносить в CVS, в проект. У тебя получается, что куча времени на отлов потенциальной ошибки существует, а куча времени на набивание - не существует? И повторю еще раз: в любом случае enum лучше. В упомянутом же "мучебнике" для ламеров прием с enum рассматривается как нечто устаревшее и отжившее. Гы.

[ Это уже грязный хак. Манипуляторы отрывать надо за такое. ]

Это уже опять пошла религия. Думаешь, сказал слово "хак" и на белого коня влез? :) Это не хак, а классическое определение константы со специальным префиксом, который играет ту же роль, что и namespace. Именно так и надо писать глобальные #define-ы, тогда и не придется тратить "куеву хучу времени" на отлов ошибок из-за повторения констант. Потому, что никаких повторений просто не будет.

[bsivko.livejournal.com]

>Константа типа char, напечатает, опять же, '0'. Ну и где оно - счастье? :)

Сейчас не удалось воспроизвести ситуацию с ошибкой из-за отсутствия типизациии у макросов, с которой бодался я пару лет назад. В любом случае она снимается конструкцией вида

#define CH ((char)'0')

но об этом мало кто помнит.

>И повторю еще раз: в любом случае enum лучше.

Я не говорил о том, что enum хуже. Использование enum для определения констант рекомендуется ведущими собаководами специалистами наравне с const, но никак не с макросами.

>У тебя получается, что куча времени на отлов потенциальной ошибки существует, а куча времени на набивание - не существует?

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

У меня константы в классе описываются крайне редко. Потому что константа на то и константа, что она одинакова для всех instance и может быть оформлена в качестве константы пространства имен или геттера.

>Это уже опять пошла религия. Думаешь, сказал слово "хак" и на белого коня влез?

Покажи справку стандарт языка, где такой префикс обязателен для всех компиляторов. Жду.

Слово "хак" означает вполне конкретное действие, которое направлено на использование особенностей текущей системы или поведения программы для достижения локальной цели, но при этом не соответствует нормам и ведет к большой жопе в долгосрочной перспективе.

Если программист для ожидания ввода пишет

std:cin >> "";

то это грязный хак.

Если у него программа при int x[100] не работает по каким-то непонятным причинам, а при исправлении на int x[1000] все вдруг работает, и при этом нет никакого анализа причин - то это также грязный хак.

В нормальных фирмах за грязные хаки увольняют без разговоров. Потому что никому не нужны 10% программистов делающих 90% ошибок в проектах.

Я понятно объяснил, что такое "хак"?

>Именно так и надо писать глобальные #define-ы, тогда и не придется тратить "куеву хучу времени" на отлов ошибок из-за повторения констант.

Способов написания "уникальных" define'ов много, и я их тут не затрагиваю.

[psilogic.livejournal.com]

[ Сейчас не удалось воспроизвести ситуацию с ошибкой из-за отсутствия типизациии у макросов ]

При желании все можно придумать - просто это редкие ситуации. При желании можно и
const int string= "";
написать, а потом удивляться, что за фигня получается, когда путается с std::string.

[ Использование enum для определения констант рекомендуется ведущими собаководами специалистами наравне с const, но никак не с макросами. ]

Ну вот потому мне тот собаковод и не понравился, что уперся в const :)

[ Если есть возможность отловить/пресечь потенциальную ошибку компилятором, то эту возможность нужно использовать ]

Так и с #define-ом есть возможность пресечь - используй достаточно уникальные имена, а не "CH" и не "WIDTH1". :)

[ Покажи справку стандарт языка, где такой префикс обязателен для всех компиляторов. ]

При чем тут компиляторы? Это просто традиция - облегчать себе жизнь префиксами. Скажем, в виндах пишем не TIMER, а WM_TIMER, где префикс WM_ - есть аббревиатура от Window Message. Та или иная схема префиксов должна быть.

[ Слово "хак" означает вполне конкретное действие, которое направлено на использование особенностей текущей системы или поведения программы для достижения локальной цели, но при этом не соответствует нормам и ведет к большой жопе в долгосрочной перспективе. ]

Ну так слезай с белой лошадки, Всякие WM_ или Class__ под это определение не подходят и, следовательно, хаками не являются. :)

[bsivko.livejournal.com]

----------defence mode off----------------------------
Что ты не затронул ещё кучу особенностей макросов. И почему-то для тебя главное кол-во букв в коде, нежели другие показатели качества кода и его сопровождения.

1. Макросы могут быть раскрыты неожиданно, раскрываясь в непредсказуемые конструкции. С этим хорошо знакомы программисты, которые хоть раз использовали 2-3 уровня макросов.
Типичный простой пример:

#define WIDTH1 20
#define WIDTH2 25
#define TOTAL_WIDTH WIDTH1 + WIDTH2
#define HEIGHT 10
#define PER TOTAL_WIDTH*2 + HEIGHT*2
#define AREA TOTAL_WIDTH * HEIGHT

Второй пример:
#define ABORT(msg)\
std::cerr << msg << std::endl; exit(1);

Они конечно лечаться, но приличным трудом программистов, в основном методом расставляния скобок различного типа во все дыры без каких либо внятных средств отладки.

2. Макросы трудно отлаживать. Потому что синтаксический анализатор и прочие средства добираются только после того, как макросы прошлись табуном по коду, в результате мест ошибки будет совсем не там, где на неё показывает компилятор.

Пример (действующий для большинства компиляторов):

#define HUNDRED (10 ** 2)

int main() {
for(int i = 0; i < 10; ++i) {
std::cout << i << ":" << (HUNDRED*i) << "\n";
}
return 0;
}

Ошибка в одной строке, компилятор указывает на другую, при чем появляется она не на всех компиляторах.

3. Особенности макросов нужно знать и постоянно за ними следить и держать в голове. Потому что потом придется исправлять все долго и мучительно. Скобки уже были показаны ранее. Немного остальных особенностей:

3.1
#define INT_PTR int *

int main() {
INT_PTR one, two;
one = two;
return 0;
}

3.2
#define DOUBLE (value) ((value) + (value))
int main() {
for(int i = 0; i < 10; ++i) {
std::cout << DOUBLE(i) << std::endl;
}
return 0;
}

3.3
#define TOP 3.0; // Высота окна.
#define BORDER 0.7; // Ширина кромки.
#define REAL TOP- BORDER

int main() {
float real = REAL;
std::cout << real << std::endl;
}

3.4
#define SQR(x) ((x)*(x))
int main() {
int i = 0;
while( i < 10 ) {
std::cout << i << ":" << SQR(++i) << std::endl;
}
return 0;
}

3.5
Сколько аргументов у такого

#define MACR( one

[Error: Irreparable invalid markup ('<int,>') in entry. Owner must fix manually. Raw contents below.]

----------defence mode off----------------------------
Что ты не затронул ещё кучу особенностей макросов. И почему-то для тебя главное кол-во букв в коде, нежели другие показатели качества кода и его сопровождения.

1. Макросы могут быть раскрыты неожиданно, раскрываясь в непредсказуемые конструкции. С этим хорошо знакомы программисты, которые хоть раз использовали 2-3 уровня макросов.
Типичный простой пример:

#define WIDTH1 20
#define WIDTH2 25
#define TOTAL_WIDTH WIDTH1 + WIDTH2
#define HEIGHT 10
#define PER TOTAL_WIDTH*2 + HEIGHT*2
#define AREA TOTAL_WIDTH * HEIGHT

Второй пример:
#define ABORT(msg)\
std::cerr << msg << std::endl; exit(1);

Они конечно лечаться, но приличным трудом программистов, в основном методом расставляния скобок различного типа во все дыры без каких либо внятных средств отладки.

2. Макросы трудно отлаживать. Потому что синтаксический анализатор и прочие средства добираются только после того, как макросы прошлись табуном по коду, в результате мест ошибки будет совсем не там, где на неё показывает компилятор.

Пример (действующий для большинства компиляторов):

#define HUNDRED (10 ** 2)

int main() {
for(int i = 0; i < 10; ++i) {
std::cout << i << ":" << (HUNDRED*i) << "\n";
}
return 0;
}

Ошибка в одной строке, компилятор указывает на другую, при чем появляется она не на всех компиляторах.

3. Особенности макросов нужно знать и постоянно за ними следить и держать в голове. Потому что потом придется исправлять все долго и мучительно. Скобки уже были показаны ранее. Немного остальных особенностей:

3.1
#define INT_PTR int *

int main() {
INT_PTR one, two;
one = two;
return 0;
}

3.2
#define DOUBLE (value) ((value) + (value))
int main() {
for(int i = 0; i < 10; ++i) {
std::cout << DOUBLE(i) << std::endl;
}
return 0;
}

3.3
#define TOP 3.0; // Высота окна.
#define BORDER 0.7; // Ширина кромки.
#define REAL TOP- BORDER

int main() {
float real = REAL;
std::cout << real << std::endl;
}

3.4
#define SQR(x) ((x)*(x))
int main() {
int i = 0;
while( i < 10 ) {
std::cout << i << ":" << SQR(++i) << std::endl;
}
return 0;
}

3.5
Сколько аргументов у такого

#define MACR( one<int, float> )

макроса?

И самое страшное не то, что могут быть ошибки. А то, что если ошибка есть, а программа скомпилируется во что-то квази-работающее.
---------------------------

При всем этом макросы являются единственным решением для таких задач, как защита от повторной компиляции, условная компиляция блоков кода.

Макрос это инструмент. И как показывает практика, он хорошо работает только в исключительных случаях. Рекомендуется использовать const и enum для определения явных констант, inline для исключения накладных расходов вызова функций, template для определения множества однотипных функций, namespace для избежания коллизий по именам. Все. Для макросов места практически не остается.

А ты про свою религию брось. Если там общаешься постоянно с сумашедшим домом, то это не говорит о том, что все такие.

[psilogic.livejournal.com]

[ Что ты не затронул ещё кучу особенностей макросов. ]

А потому, что я не люблю бездумные "глобальные" правила для ламеров. В тех ситуациях, когда макросы хуже, зачем же я их буду защищать? :) Скажем, для мелких функций inline или template+inline лучше, чем #define со скобками. Там, где макросы хуже, глупо их хвалить. А там, где макросы не хуже, нет смысла их ругать. Глобальные обобщения - это для чайников :)

[ab83.livejournal.com]

Спасибо.

И эта... Я не хотел, чтобы Вы втянулись в спор. Извините, если что.

[psilogic.livejournal.com]

Да что вы. Это развлекает.

[nefedor.livejournal.com]

Так получилось, что я совсем недавно смотрел упомянутого мейерса, причем не первое издание древнего года, а третье и пока последнее, кажется, 2005го.
Так вот, пару слов.
Во-первых, про enum. Как правильно заметил бсивко, мейерс именно что активно рекомендует использовать enum. Он просто говорит, что в программистских кругах сложилось название для подобного использования enum-а - "enum hack". Но из текста (английского по крайней мере) совершенно никак не следует, что это нечто грязное и нечистоплотное, наоборот, этот "хак" преподносится как нечто, что следует знать и использовать.
Во-вторых, про пункт 3, то есть, про константы - члены класса. Тот же мейерс в той же главе пишет, что для типов int, char и bool объявлять переменную в .cpp не нужно - достаточно декларации в хедере, что является стандартом языка. Правда, некоторые старые компиляторы этого могут не поддерживать, но более-менее новые должны. Поэтому писанины становится меньше в два раза.
Ну и в-третьих, пустые холивары всегда бывают от абсолютизации чего-то. Того же мейерса делать непогрешимым кумиром вряд ли стоит. С другой стороны, также вряд ли стоит утверждать его ламерство, в то время как он является распространенным и уважаемым автором для многих программистских коллективов. Скажем, ты можешь не разделять их и бсивко воззрения на минимизацию времени на отладку и поиск багов, но они в свою очередь, могут не разделить твое видение себя в их рядах в случае поиска работы... :)

[psilogic.livejournal.com]

[ Он просто говорит, что в программистских кругах сложилось название для подобного использования enum-а - "enum hack". ]

Вот силами таких текстов и сложилось.

[ Правда, некоторые старые компиляторы этого могут не поддерживать, но более-менее новые должны. Поэтому писанины становится меньше в два раза. ]

Здесь вы правы, убедили - поддержка старых компиляторов требуется редко. С сегодняшнего дня начинаю чаще юзать const для констант.

А какое ваше мнение по поводу функции max, где предлагается сделать параметры ссылками?

[nefedor.livejournal.com]

Мирослав, в свете нашего давнего знакомства еще на кураевщине, предлагаю на "ты", ладно?

[Вот силами таких текстов и сложилось.]

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

[А какое ваше мнение по поводу функции max, где предлагается сделать параметры ссылками?]

Нормальное. Если она будет использоваться для объектов с тяжелым конструктором копирования, то выгоды очевидны.

[psilogic.livejournal.com]

[ Если она будет использоваться для объектов с тяжелым конструктором копирования, то выгоды очевидны. ]

А если будет использоваться для простого типа?

[nefedor.livejournal.com]

Тогда, я бы сделал без ссылок. Вопрос только в том, может ли быть заранее известно, что она не будет использоваться только для простых типов? Всегда есть вероятность, что в будущем проект разрастется и будет надстроен монстрами, для которых понадобится max...