Хочу создать пару из объектов, в классах которых нет конструктора по умолчанию, так что строка



вызывает ошибку no appropriate default constructor available где-то в глубинах STL

Это логично. Поэтому я пишу



поскольку конструктор CSpecSizeModel принимает 1 целочисленный параметр.

Но и это вызывает ошибку error C2086: 'CSpecSizeModel i' : redefinition

Почему?

Попробуй воспользоваться ф-й 


Добавлено через 1 минуту и 5 секунд
возможно компилятор принимает 

за объявлени функции, хотя я не уверен в этом....

1) Сперва я сделал тайпдеф:



не помогло.

2) Потом я записал вот так



и тогда стало компилироваться.

Это действительно объявление функции.

Добавлено через 2 минуты и 36 секунд
Если конструктор CSpecSizeModel для i не является explicit, то достаточно будет записать так:

а можно полюбопытствовать в роли чего в

выступает i ?

В роли имени параметра функции 

а тип где?

Добавлено через 26 секунд
или я чето не догоняю....

просьба сжалиться и объяснить чуть подробнее 

В стандарте написано, все что может быть объявлением, должно быть объявлением. поэтому код:
pair<CSpecSizeModel,CSpecSizeModel> ans(CSpecSizeModel(i),CSpecSizeModel(i));
компилятор видит, как:
type1 ans(type2 (i), type2(i));
Из которого убираются лишние скобки:
type1 ans(type2 i, type2 i);
и лишние имена переменных:
type1 ans(type2, type2);
А это уже объявление функции.

Сильно меня перехваливать не стоит. Я позаимствовал этот способ демонстрации из книги: "Герб Саттер - Новые сложные задачи на C++"

Кажись, никто не осветил собственно решение этой коллизии, вот оно (взято, естественно, всё оттуда же):

Слишком много скобок. Проще C-каст сделать.

Нет уж, хватит с меня С-кастов...

а чем
std::pair <X,X> p = std::make_pair(X(i), X(i));
не подходит?

Это сообщение отредактировал(а) baldina - 8.12.2007, 03:24

Много буков 

Добавлено @ 11:36

А чем функциональное преобразование лучше?

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

тем, что оно ограничивает область преобразования. Тем, что я знаю, делает ли компилятор физические преобразования (static_cast), логические (reinterpret_cast), вниз по иерархии классов (dynamic_cast), или же опасную отмену константности (const_cast).

Разделение обязанностей. Разделяй и властвуй.

ДжэкИФ, в случае сложного типа ты не сможешь отменить константность и сделать прочие опасные преобразования .
В принципе, кастить c-cast'ом противопоказанно в шаблонном коде, когда ты не знаешь, что из себя представляет T. В других же случаях можно, но я не рекомендую - плохой стиль, плохая привычка .

Это как же? Функциональный каст делает абсолютно те же преобразования, что и C-каст, просто синтаксис другой.


Ну, тогда тебе надо было записать


Так сказать, вариант специально для слепых 

Что и так можно?

А где ты тут видишь функциональный каст? 

Вот так


можно.

Сранно, сранно...

Добавлено через 29 секунд
Ой, извините, дважды букву "т" пропустил .

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

Точно так же отработает и функциональное преобразование, которое ты выше использовал, ибо в случае одного аргумента это почти то же самое, что C-каст.

Добавлено через 53 секунды

А чего странного-то?

А ты букву "т" убери .

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

пожалуйста:



В результате выводится значения совсем левых мест памяти, а не C::c1, C::c2, что логично следует данного кода.

Добавлено через 24 секунды
а dynamic_cast<> вернул бы 0.

Добавлено через 1 минуту и 32 секунды

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

Так Джеки, я сразу подчеркнул, что я говорю про сложные типы. Про указатели и прочие примитивные типы речи не шло - с ними и так всё понятно: ТАБУ.
А вот со сложными типами никаких опасных преобразований сделать невозможно. Под сложными я понимаю все пользовательские типы, кроме перечислений.

Опять же, если код шаблонный, то ты просто пессемизируешь и полагаешь, что T - примитивный тип, соответственно никаких c-кастов не используешь. Если же ты точно знаешь с каким типом работаешь, то можешь пользоваться как тем, так и другим, но тут есть очень опасные грабли - ты можешь по привычке случайно воспользоваться c-кастом. Тогда капздец. Вот именно поэтому я рекомендую ими не пользоваться вообще и не пользуюсь сам. Правда, то что ф-циональный каст есть по сути то же, что и c-каст - для меня это, мягко говоря открытие...

ну так приведение вниз по иерархии только над указателями и может применяться.

Ну так в свете беседы о сложных объектах я и не понял о чём вообще речь .
Ладно, разобрались и хорошо .

Какой ещё ноль?

Ты несколькими постами ранее написал такой код:


CSpecSizeModel(i) - это явное преобразование в функциональной нотации.
(CSpecSizeModel)i - это будет явное преобразование в cast-нотации.
Оба эти преобразования эквивалентны. Только в случае с cast-нотацией здесь не надо будет ничего обрамлять дополнительными скобками, чтобы компилятор не считал ans функцией, на что я и указал.


Да шо вы говорите?

Вот это


видимо, неправильное преобразование?

Это сообщение отредактировал(а) UnrealMan - 9.12.2007, 14:03

dynamic_cast<...> в случае неправильного приведения вниз по иерархии по указателю вернёт NULL, по ссылке - std::bad_cast.
а C-каст и в том, и в том случае просто вернёт неправильные указатель/ссылку.


Хорошо. Ещё по ссылке.



Да, такой оператор неверен. Он не должен скомпилироваться.


Это вообще-то в данном случае вызов конструктора.

Да шо вы говорите? 



А вот что по этому поводу говорит стандарт:


CSpecSizeModel(i) - это явное преобразование в функциональной нотации, выполняемое при помощи конструктора.

Это сообщение отредактировал(а) UnrealMan - 9.12.2007, 16:07

UnrealMan, а как тебе предложение в будущем попробовать излагать информацию не как насмешку, а как повествование? Мне кажется, что в том, что кто-то чего-то не знает или в чём-то заблуждается нет ничего смешного.

Я всегда думал, что имя класса, за которым в скобках идут аргументы конструктора, создаёт в выражении временный объект с помощью соответствующего вызова конструктора.

Не так?

Добавлено через 1 минуту и 18 секунд

А что это значит?

Не всегда.

Очень хорошо объяснил bsa - советую прочитать. А ещё лучше прочитать указанную им книгу.

Вопрос: если человек чего-то не знает, то почему считает возможным вступать в спор? Зачем так рьяно выдавать свои домыслы за действительность? Может, лучше сначала посмотреть в стандарт? Или хотя бы научиться добавлять к своим словам "IMHO"? Ведь народ сюда приходит не за бабушкиными сказками, не так ли? 

Цитата(archimed7592 @  9.12.2007,  16:05 )

UnrealMan, а как тебе предложение в будущем попробовать излагать информацию не как насмешку, а как повествование?

А ты сам-то часто следуешь своему предложению? ;)

Это уже проблемы конкретного человека. Только не вижу здесь ничего смешного. Если научишь как найти в этом смешное, то буду рад продлевать себе жизнь искренним смехом .



Нередко ;).

Что ни день, то открытия... Жаль...

Ладно.

Будешь пользоваться таким приведением? Я - нет. UB'a мне только в коде не хватало. Но за инфу спасибо.


вот. главное, что никакого UB - чётко и ясно указано, с помощью какой функции будет произведено преобразование.

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

Добавлено через 4 минуты и 42 секунды

Буду, если оно точно сделает то, что я ожидаю.


С помощью той же, что и для каст-нотации.

!  archimed7592

Если тебя что-то не устраивает в форуме, то ты можешь обратиться в соответствующем разделе к администрации с конструктивными предложениями или просто жалобами. Дальнейшее обсуждение здесь считаю недопустимым и расчитываю на твоё понимание.

Да ессно, это дело личных предпочтений. Некоторые считают, что лучше писать 0 == a, чем a == 0, тем самым минимизируя вероятность ошибки. Я таких ошибок не делаю уже года 4 и считаю излишним. О кастах сказать такого не могу - потому и не пользуюсь чем попало. Наверное у тебя огромный опыт, раз ты так легко и непринуждённо используешь их.

downcast посредством dynamic_cast выполняется значительно медленее, чем посредством static_cast. Это несколько сказывается на предпочтениях...

.

Да нет, когда делается static_cast ясно и понятно(с большой долей вероятности), что делающий осознаёт что делает(извиняюсь за масло масленное). Когда же делается опасный каст(которых, как оказалось два), не всегда понятно, здесь явно корректное приведение, или кто-то где-то облажался.

JackYF, насколько я понял, имел в виду сравнение dynamic_cast vs static_cast.

 .
specialized-cast vs c-cast.

Все могут ошибаться. Я был уверен, что static_cast<> не может делать приведения вниз по иерархии. Ошибся. Я и сейчас в недоумении, почему ему разрешено это делать, но со стандартом не поспоришь.


  Как можно точно сделать UB?..



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



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

Такая возможность есть почти везде. Ты ловишь исключения от new? 



Неа. Downcasting static_cast'ом - распространённая практика, а вот dynamic_cast'ом - ИМХО, нужно переписывать .
Вообще говоря, dynamic и const пользовался раза 2-3 в жизни. А reinterpret вообще не юзал.

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


К счастью, не сталкивался с таким.
Downcasting сам по себе в плюсах - вещь, использование которой желательно ограничивать...

Ты тоже будешь делать downcasting static_cast'ом?

P.S. Ребята, вы меня пугаете...

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

Ну что ж... каждому своё мнение 

Почему? И главное - почему именно в плюсах? Я не спорю, что зачастую лучше от него отказаться, но каким-то правилом это делать не стоит 


Ну, всё же на мой взгляд динамик нужен достаточно часто. Конст и реинтерпрет - либо изврат, либо врапперы над чисто сишными библиотеками. Хотя, в некоторых случаях, если я уверен в кастинге, конечно, предпочту статик динамику - в силу перформанса. Хотя, если честно, чаще использую qobject_cast, чем динамик (это, конечно, не одно и то же, но динамик в чистом виде мне редко нужен)   


Всмысле перписывать? На что? Или перепроектировать? 


Ну, вообще, по-моему вначале речь шла про:
1. Равны ли c-cast b functional cast.
2. Нужны ли они.

Ну вот и я об этом. Каждый отказ - лишний кирпич в фундамент безопасности программы.

Может вопрос не в тему, но раз упомянули - данную книгу нашел, нужно самообразовываться   . Но там написано, что - это вторая книга - продолжение книги  "Решение сложных задач C++" Эту книгу на русском что-то найти никак не могу. Может у кого есть ссылка. Нашел только на английском.
тут

Это сообщение отредактировал(а) Random13 - 10.12.2007, 01:34

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

Причем указатели pa и pb будут естественно указывать на разные области памяти

Я уже сказал - скорость выполнения.


Есть много способов 


Это совсем не очевидное следствие.


Вопрос: откуда исходит эта возможность? Хочешь, я тебе сейчас докажу, что передавать аргумент по ссылке в функцию push_back вектора неправильно?

Рассмотрим пример


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


Опять 25. const_cast может применяться для избежания дублирования кода, reinterpret_cast - для преобразований
char * <--> unsigned char *. И это только примеры, которые сразу вспоминаются.


Разговор про dynamic_cast завёл не я, а JackYF. Зачем - это вы у него спросите 


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


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

Надо-же я всегда себе деревья по другому представлял, для меня вниз по иерархии(downcasting) - это от производного к базовому, в этом случае противоречия нет...
А где вы встречали такую терминологию?
И кстати причем здесь dynamic_cast? Вот всегда так бывает, начинается все с одной темы, потом обсуждение заходит неизвестно куда))

http://en.wikipedia.org/wiki/Downcasting


В литературе  Какой конкретно не помню.

Я встречал в UML диаграммах.
Но по-моему в аппкастинге тоже могут быть проблемы в случае множественного наследования. Там как-то делается уже подзабыл, чтобы вместо общего 2 раза повторяющегося родителя стоял на него поинтер - тогда проблем не будет.

Это сообщение отредактировал(а) Random13 - 10.12.2007, 15:23

наоборот. Вниз по иерархии - от базового к наследнику.


Я принял этот аргумент.


Хорошо. Добавляю "имхо". Для меня это почти очевидно.


Как частный случай С-каст vs С++-каст.


придётся тебе читать тему сначала   

M archimed7592

Да, уж, от темы то мы "малость" отошли :).

С конст-кастом не поспоришь, но, как у const_cast'а, так и у copy-paste есть как плюсы, так и минусы.
Ну а reinterpret - я понимаю, что я обманываю сам себя, но делаю я это посредством двойного статик-каста(где встретил такой способ точно не помню, но там как-то хитро объяснялось, что это гут ).

Это сообщение отредактировал(а) archimed7592 - 10.12.2007, 17:41

Цитата(archimed7592 @  10.12.2007,  17:41 )

но делаю я это посредством двойного статик-каста

А почему бы сразу 10 static_cast-ов не вставить? Любое преобразование указателя к указателю через reinterpret_cast можно заменить двумя преобразованиями static_cast

cv T1 * → cv void * → cv T2 *

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



Это сообщение отредактировал(а) UnrealMan - 10.12.2007, 19:30

тут говорится

zkv, точно . Спасибо, а я забыл про этот ресурс... как раз почитаю чего новенького есть.

Цитата(zkv @ 10.12.2007,  21:47)

Цитата(archimed7592 @  10.12.2007,  17:41 ) где встретил такой способ точно не помню, но там как-то хитро объяснялось, что это гут тут говорится

Цитата

Дело в том, что стандарт совершенно не гарантирует то, что указатели на разные типы данных имеют одинаковый размер и структуру. reinterpret_cast выполнит приведение что называется «в лоб», и при этом не будет никакой гарантии того, что при этом не произойдет потери данных и полученный указатель будет валиден. Используйте двойной static_cast вместо reinterpret_cast. Стандарт гарантирует, что указатель на void имеет достаточный размер, чтобы уместить указатель на любые данные.

Вылезая из-под стола, замечу, что ребята скромно промолчали о том, что стандарт очень мало чего гарантирует в отношении двойного static_cast через cv void *, если начальный и конечный указательные типы не совпадают 

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

Объясните мне, как указатели могут иметь разный размер.
Для извращенцев есть такой вариант

Цитата(Lazin @  11.12.2007,  08:51 )

Объясните мне, как указатели могут иметь разный размер.

Если иметь в виду указатели на объекты, то я не знаю таких платформ. И вряд ли когда-нибудь буду иметь с ними дело  Даже если бы двойной static_cast был переносимее (а стандарт не даёт никаких поводов так считать), я бы всё равно предпочёл reinterpret_cast - потому что читабельность кода для меня важнее, чем достижение мифической переносимости реальной программы, которая по-любому будет писаться с учётом специфики платформы.

В случае преобразований char * <--> unsigned char * я всегда C-cast использую.

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