Добрый день.
Заинтересовал такой вопрос, почему вариант

работает, а вариант

нет.

Из каких побуждений могли разрешить первый вариант и запретить второй?

— из тех, что оператор "=" не может быть перегружен, а "+" — может, думаю.

ответ вообще не в тему.
вопрос не в синтаксисе, а почему эту возможность не вложили.

Это сообщение отредактировал(а) gambit - 27.2.2010, 00:14

Первый вариант работает, потому что оператор "+" для строки перегружен. Типа

Для того, чтобы допустим был второй вариант, нужно чтобы было определено implicit-преобразование из int в string. Типа

Но этого не сделали. Потому что просто так.

Из соображений оптимизации скорее всего, но каких... Надо спросить на форуме майкрософт)

Никаких там оптимизаций нет и быть не может.

Просто так, даже мухи не....


почему?


это реальный код платформы .net, или полет вашей фантазии?

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


Потому что негде. Это же очевидно.


Это реальный код. Хочешь я тебе напишу класс CoolString, для которого и первый и второй вариант будет работать + он будет полностью совместим со стандартным string'ом.

А почему такую весчь не реализовали путем неявного приведения? Ведь int всегда приведется к стрингу?

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

а где ниб в рефлекторе его можно найти, а то я что то невижу(((

Потому что сейчас можно неявно привести int к string, но нельзя неявно привести string к int. Если бы были возможны оба преобразования, то как разрулить такой код


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

А чёрт его знает.... может он вообще нативный   

а причем здесь это? неявное приведение всегда только в одну сторону.

мы можем родителя привести к потомку, но не потомка к родителю.
мы можем int привести к int64, но не наоборот.



так вы и не колитесь, где же вы его нашли, если он реальный.

кроме того если тот код реален, то как вы объясните это???


что в классе string знак + перегружен для всех возможных вариантов???

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

!  PashaPash

+10%

Вот класс. Можно его привести к int, и можно int привести к нему.... неявно.



Смотрим:

Работает!


Как где? Написал! Не веришь, что он реальный - скомпилируй и запусти.


В данном конкретном примере есть только неявное преобразование из string в int.


Это сообщение отредактировал(а) PashaPash - 27.2.2010, 02:53

Да ничего там не перегружено. Это фича на уровне компилятора. Вызывается String.Concat (который принимает обжекты).

Почему нельзя присваивать инты стрингам? ИМХО, решили, что это может привести к лишним случайным ошибкам (ну т. е. тот случай когда лишняя "неявность" - это плохо). Объективно тут не ответишь (плохо или нет), но я согласен 

Ну и для параноиков - надо вызывать ToString, который возовет Int32.ToString, а не пользоваться конкатом, примающим обжекты и, как следствие, вызывающий боксинг числа (о, ужас - это ж дикие затраты!). Запомните это хорошо!

А это уже непринципиально, разруливает ли это компилятор или рантайм. В термах же языка это именно перегрузка оператора.


Посмотри выше про неоднозначность Console.WriteLine(s + i);

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

Если ты о моём примере, то там int сначала преобразуется в string, а уже потом вызывается перегруженная версия Concat, которая принимает два параметра string.

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

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

В каком? С райт-лайном? Предполагаю, что там боксится i, а затем вызывается Concat.

Добавлено через 3 минуты и 56 секунд
И.. если придираться. Пример с якобы перегруженным оператором + (ок, детали реализации неважны, смотрим результат) неверен. Как раз прямое использование + (без вызова ToString ведёт к боксингу и Concat-у с обжектами. А вызов ToString - к Int32.ToString + конкат со стрингами.