Всякий раз перед использованием функции, её необходимо пересматривать (для того, чтобы быть рациональным?)

[v04bvs]

В С++ (языка ##c++ не знаю), перевод из типа в тип выглядит так:

Код: Выделить всё

x = y;//копирование с переводом
x(y);//инициализация с переводом
f(y);//вызов функции с параметром не того типа
(const my_type*)x;//это если явно захотелось;)

А как же staic_cast, const_cast, dynamic_cast, reinterpret_cast, boost::lexical_cast ? И вообще имхо C-приведение не рекомендовано. Не знаю почему правда

[Uncle_Theodore]

А что такого негламурного в stringstream'е? По-моему, очень интуитивно понятный вариант.

[deninok]

А как же staic_cast, const_cast, dynamic_cast, reinterpret_cast, boost::lexical_cast ? И вообще имхо C-приведение не рекомендовано. Не знаю почему правда

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

[v04bvs]

А как же staic_cast, const_cast, dynamic_cast, reinterpret_cast, boost::lexical_cast ? И вообще имхо C-приведение не рекомендовано. Не знаю почему правда

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

По-моему самым логичным и понятным является джавовский подход Но это конечно не zero-overhead, да
Аргумент про поиск в исходном тексте я знаю, но не принимаю. Зачем там что то искать? Может унарный минус тоже оформим как-нибудь вроде static_minus<double>
Я подумал - это хорошо подходит например потому что можно свои касты выдумать, и они будут органично сливаться с существующими, вроде my_cast<double>( static_cast<float>(x) ). Учитывая маниакальное пристрастие тов. Страуструпа перегружать всё и вся, это выглядит, имхо, правдоподобно.

[drBatty]

И вообще имхо C-приведение не рекомендовано. Не знаю почему правда

Тут уже писалось почему. У меня это просто пример, для совместимости с библиотеками С(например с int printf(const char *, ...)). ИМХО явное преобразование типов надо избегать, в т. ч. и плюсовые *_cast. А вот неявное очень удбно(имхо, конечно).

А что такого негламурного в stringstream'е? По-моему, очень интуитивно понятный вариант.

В данном конкретном случае, я тоже не понимаю, чем KukMan'а этот вариант не устроил...

Может унарный минус тоже оформим как-нибудь вроде static_minus<double>

может лучше my_type my_type::operator-() const; ?

[deninok]

Аргумент про поиск в исходном тексте я знаю, но не принимаю. Зачем там что то искать? Может унарный минус тоже оформим как-нибудь вроде static_minus<double>

Брюс Эккель в своей книге "Философия С++" приводит такой пример. Представьте, что вам принесли неработающую (или работающую неправильно) программу на С++, в которой используется явное приведение типов в стиле С. Известно, что явное приведение типов может быть источником трудноуловимых ошибок (например, потеря данных). И вот вы решили искать в этой программе все места с явным приведением, чтобы их проверить. Вопрос: как их искать?
Выражение типа:

Код: Выделить всё

a = (b)c;

не очень-то бросается в глаза. Зато выражение:

Код: Выделить всё

a = static_cast<b>(c);

найти гораздо легче, в том числе и с использованием автопоиска в редакторе (по выражению "_cast", например).

[drBatty]

Известно, что явное приведение типов может быть источником трудноуловимых ошибок (например, потеря данных).

Приведите пример, пожалуйста. Если вы о
(class*)
(
(void*)
(class*)
)
то тут беда не в приведении, а в (void*), который можно найти поиском.
Во всех(возможно почти) остальных случаях преобразование типов может быть не явным, и его будет не видно.

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

ЗЫЖ Просьба к модераторам: отрежьте пожалуйста обсуждение типов от обсуждения вложенных функций(где-то с #27).