Rockie, он хотел преобразовать из одного в другой тип, одинаковые по внутреннему представлению. Лучше всего это делать так, как сказал, JackYF. Я бы правда сделал конструктор с explicit (при разрастании структур случайные преобразования могут оказаться некстати). Да сишные кастования не использовал, а просто бы вызвал конструктор. Скажем так:

Или так:

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

Любитель, а какой смысл создавать объект из такого же объекта? Если можно создать экземпляр этого же класса и пользоваться встроенным присваиванием. Возможно, такая необходимость и может возникнуть, но врядли это необходимо в данном случае. 

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

Я вообще тоже новичок......и как я знаю то, что преобразование в C++ лудше делать спомощью 
 static_cast<тип>(значение)

Абсолютно верно - типа преобразование при помощи скобок - старый стиль Си...
(Хотя у Лаффоре основной аргумент использования static_cast - это то, что его поиском удобнее искать в случае чего)

Но привычка вторая натура - никак не могу себя заставить такое длинное писать   

B(a) – это преобразование типа, эквивалентное (B)a


По-моему, ничем оно не лучше, кроме тех случаев, когда cast- или functional- форма преобразования делает не то, что на самом деле требуется.

Это вызов конструктора. Для типа, не являющегося классом - это приведение в стиле функций.


  cast == привденение. Под преобразованием обычно понимают именно преобразование (например, строки в число).


1. Оно явно виднеется в коде невооружённым глазом.
2. Оно не позволит сделать многое, что позволят сделать кастования в сишном стиле. Типосейфити очень важная вещь в плюсах.

Этого я не знал. Можно примерчик? 

Тут Страуструп пишет:

Мда... Век живи - век учись.

Все равно дураком помрешь...

Да что ты говоришь? :-)

Хочешь сказать, вот здесь


вызов конструктора?




Что приведение типа, что преобразование типа – я как-то это не различаю.


Угу, и занимает много места :-)


Я это прекрасно знаю, потому и написал:


Например, в ситуации, когда cast- или functional- форма приведения оказывается эквивалентной a static_cast followed by a const_cast, а нужно только static_cast-приведение, следует использовать именно оператор static_cast. Если указатель/ссылка базового типа приводится к указателю/ссылке производного, то следует избегать возможного приведения в виде reinterpret_cast (которое наверняка будет ошибочным). А вот зачем использовать оператор static_cast в приведении, скажем, void * к int * ? Или же в приведении вроде B(a), как это делалось выше? С чем тут можно спутать static_cast?

Это сообщение отредактировал(а) UnrealMan - 19.12.2006, 11:53

UnrealMan, неточность у тебя.



Видел? А у тебя и А и В - классы.

Может, я ещё не проснулся и поэтому туго соображаю. Покажи пальцем, где у меня неточность.


Вот именно, что у меня это классы, а B(a) при этом – «приведение в стиле функции», где нет никакого вызова конструктора. И там, где B(a) приводит к вызову конструктора, это всё равно «приведение в стиле функции».

Это сообщение отредактировал(а) UnrealMan - 20.12.2006, 09:17

UnrealMan, другой пример.


Для последнего случая компилер часто использует оптимизацию, для предотвращение лишнего копирования. Впрочем не всегда.

Суть в том, что приведение от двух элементов невозможно (очевидно). В твоём примере также вызывается конструктор для конструирования временных объектов. Если интересует ссылка на стандарт - приду домой посмотрю, приведу.


А зря. Это разные вещи.

Хорошо, может вызваться копирующий конструктор класса B (именно за счёт B(a) – как дополнение к вызову конструктора за счёт инициализации объекта b). И что, из-за этого преобразование B(a) ты будешь называть вызовом конструктора? :-)


Преобразование возможно.


Приведение – это преобразование единичного выражения.

Это сообщение отредактировал(а) UnrealMan - 21.12.2006, 10:18