компилятор вообще компилирует?
date date::operator++(int)
Приведу пример, чтобы понять, что я имею в виду. Например, у нас есть оператор >
Его можно реализовать так:
date operator>(date a, date b) {}
Что тоже самое, что и:
date date::operator>(date b) {}
P.s. Если я укажу знак '>' в программе, то программа будет ожидать обьект слева от себя и справа от себя.
Тогда получается, что date date::operator++(int) эквивалентен:
date operator++(incremented_class_object, int b) {}
То есть оператор ++ должен ожидать слева и справа от себя обьекты...
P.s. Я знаю, что int - это фиктивный параметр - костыль, чтобы отличить постфиксный инкремент от префиксного. Вопрос в другом
Это и есть ответ на вопрос, нет?
Компилятор знает про фиктивность и никакие два объекта не ожидает
Ааа... то есть внутри класса операторов у инкремента отдельно прописано про фиктивный параметр?
Какие-то выдуманные термины пошли.. да, компилятор всё знает и понимает
не думаю что там что то прописано, просто компилятор распознает эту синтаксическую конструкцию.
Просто если не прописано, то после a++ компилятор должен ожидать int и выдавать ошибку компиляции, если после постфиксного ++ ничего нет
Префисный и суффиксный применяется к объекту класса, какой int? Сказано же "фиктивный" для отличия префиксного и суффиксного
В примере я имел в виду перегруженный оператор для собственного класса с указанием фиктивного параметра int
Синтаксический разбор - самостоятельный вопрос. Ошибки весьма говорящие в этом смысле: i++ 42; > CLang: error: expected ';' after expression > GCC: expected ';' before numeric constant Допуск перегрузок с сомнительными сигнатурами едва ли повлиял бы на грамматику.
"сомнительными сигнатурами" - а разве перегружают не при помощи фиктивного int?
Это знает компилятор, фиктивный на то и фиктивнвй
При помощи. Показалось, что Вы подумали в сторону того, что одно лишь разрешение таких сигнатур в общем случае должно каким-то образом влиять на разбор выражений.
Да, я так и подумал
Вот я и ответил)
Окей, спасибо
Обсуждают сегодня