Свой компилятор(С++'о подобный)

[Пепел Феникса]

Программисту логично, что b = b + 1 и b += 1 это одно и то же, а вот для компилятора это совершенно разные вещи. Можно конечно выражать += через оператор +, но тогда код будет далеко не самым оптимальным.

я думал сделать чтоб компиль видя b=b+5 компилировал как b+=5

Есть повод подумать над своей гениальной перегрузкой, чтобы и без дублирования и не зависеть от порядка переменных (в С++ а + b не всегда тождественно b + a, если a и b разных типов, т.к. будут использоваться разные варианты перегрузки +).

это и понятно.
в принципе можно решить, подобием иерархии классов, то есть по ней можно идти только вверх(при автоприведении в операторах), а при присваинии разрешить ход вниз, но хорош ли метод?
или же разрешить компилю менять слагаемые/множители местами согласно иерархии или наличию операторов(удобно например если класс A не знает о классе B(на уровне операторов) но класс B знает об A, а выражение такого A=A+B, правда код не очень оптимален выйдет, но работать будет(естественно если класс B имеет приведение к A))

Так что думайте над своим творением более тщательно, чтобы потом не пришлось баги фичами называть

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

[pu4koff]

Сообщение от Пепел Феникса

я думал сделать чтоб компиль видя b=b+5 компилировал как b+=5

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

Сообщение от Пепел Феникса

в принципе можно решить, подобием иерархии классов, то есть по ней можно идти только вверх(при автоприведении в операторах), а при присваинии разрешить ход вниз, но хорош ли метод?

Не совсем понял как это спасёт от такой ситуации:

A operator + (A a, B b);
B operator + (B b, A a);
...
A a;
B b;
a = a + b; // Сработает
a = b + a; // Ошибка, т.к. b + a возвращает объект класса B

Сообщение от Пепел Феникса

или же разрешить компилю менять слагаемые/множители местами согласно иерархии или наличию операторов(удобно например если класс A не знает о классе B(на уровне операторов) но класс B знает об A, а выражение такого A=A+B, правда код не очень оптимален выйдет, но работать будет(естественно если класс B имеет приведение к A))

1. Не спасёт в случаях реализации перегрузки для обоих случаев порядка элементов, как в моём примере выше
2. Код будет запутан и трудночитаем. Программист не сможет так слёту сказать какой именно оператор и для какого класса вызовется в конкретном месте. Для поиска ошибок придётся больше анализировать, учитывая особенности компилятора.

Сообщение от Пепел Феникса

я тему потому и создал, чтоб выслушать советы

Ну тогда позволю себе высказать мнение (просто опишу в каком направлении я бы двигался, ни в коем случае это не совет, но может на что натолкнёт).
Так вот начнём издалека: вспомним, что все мы являемся пользователями ПК и используем всякие программы. Допустим, нужно создать документ (курсовую, к примеру). Текста много - значит используем Word (ну или Writer или как там его в Oo зовут). Пишем пишем, а потом бац... схему нужно нарисовать. Берём visio или еще какую программу и рисуем схему там. Потом эту схему сохраняем как картинку, вставляем в ворд,... а потом еще табличка сложная понадобится и придётся мучиться с ней в ворде или делать её отдельно в Excel'e... В итоге наш единый документ раскидан по разным файлам, распечатать одним кликом мы его не можем, вручную правим нумерацию страниц,... В итоге получаем несоответствие реального объекта (распечатанного единого курсовика) и виртуального его воплощения.
Теперь вернёмся к нашим операторам. Что есть + по идее? Математическая операция сложение, для которой существуют свои законы (перемена мест слагаемых и всё такое). Так же в математике есть свои правила сложения матриц, матрица + вектор,... Если брать С++, то каждый программист сам прописывает все эти правила (причём может это сделать неправильно, что-то не учесть, пропустить, или специально исказить, потому что ему так удобнее). Причем в некоторых случаях таки важен порядок слагаемых, а в некоторых - нет (матрица + вектор != вектор + матрица). Так же отдельный разговор тут с пользовательскими классами, т.к. там уже я обязан задавать правила сложения двух сотрудников, если вдруг такая глупость приспичит. Отдельный вопрос вообще в необходимость разрешения такого. Может стоит сделать + чисто математической штуковиной и позволять складывать только математические данные.
Я как программист хочу получить сумму двух матриц, но я не хочу, при использовании матриц из двух разных библиотек, вспоминать как это делается и реализовывать ради этого ручками оператор сложения (да ещё и в двух экземплярах).
Но вот как это сделать... Можно натыкать интерфейсы матрицы, целого числа, вещественного числа и, если кому нужно, пусть реализует эти интерфейсы и автоматом получает возможность краткой записи а = а + b. При этом реализация операторов будет на совести компилятора и запрещена для изменения. Можно забить и пусть все пишут неявные преобразования, чтобы втихую матрицы для сложения приводились к некоему базовому типу (это собственно возможно и в С++ и частенько используется, но если автор библиотеки об этом не позаботился, то приплыли и придётся городить огород).
В общем, я хочу больше думать над задачей (нужно ли мне вообще складывать матрицы?), чем над её реализации (а как бы мне их сложить лучше... у них и тип разный и размерность... как уж это там в математике делается...)

[Пепел Феникса]

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

есть мысль(спросоня возникла) что разрешить перегружать только +=, а + автоматический сделать(и с остальными по аналогии)
но на мой взгляд как то не оч, я прав?

1. Не спасёт в случаях реализации перегрузки для обоих случаев порядка элементов, как в моём примере выше
2. Код будет запутан и трудночитаем. Программист не сможет так слёту сказать какой именно оператор и для какого класса вызовется в конкретном месте. Для поиска ошибок придётся больше анализировать, учитывая особенности компилятора.

да вы правы.

Ну тогда позволю себе высказать мнение
...

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

[Utkin]

Сообщение от Пепел Феникса

хотя насчет интерфейсов...не знаю, помоему это как то ограничивает прогера всетаки..

Ваш язык должен иметь свою философию - обоснование использованных механизмов. Почему это ограничивает прогера? Люди придумавшие это знают об ограничении, но все равно используют данные механизмы. Почему? Нужна Вам эта перегрузка? Нужна, а зачем? Подумайте сначала над этими вопросами (и многими другими). На каждый подобный вопрос у Вас должен быть четкий и желательно предсказуемый ответ. То есть чтобы человек, изучая Ваш язык не задумывался - что это еще за едрены пассатижи? И самое главное - всегда мог найти ответ о целесообразности использования той или иной возможности. Мне кажется, что у автора языка варианта на тему "не знаю" быть не должно.

Хорошо поставленный вопрос это уже половина ответа.

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

[Пепел Феникса]

Мне кажется, что у автора языка варианта на тему "не знаю" быть не должно.

тема для этого и создавалась.

вообще поразмыслив, подумал ограничения нужны.
точнее строгие правила.
но теперь надо немного обдумать правила.
думаю:
1)запретить перегружать одновременно и += и +, только что-то одно(второе реализуется автоматически)
2)логические операторы реализуются группами(группа минимум это == и !=(причем достаточно и одного, второй может быть дополнен автоматом), группа максимум это >=,<=,<,>,==,!=(аналогично дополнение пары))
3)наследование как в Джава и ДотНет(один родитель, множество реализаций интерфейса)
4)сборка мусора через подсчет ссылок(автомат, с возможностью освободить объект ранее(но компиль будет отслеживать обращение к пустому объекту))
5)концепция ссылок, чтото близкое к Obj-C, обращение в ноль выдаст исключение(данное поведение контролируемо), но обработчик по умолчанию его не покажет(игнор).
6)ссылки авто-обновляемы, то есть двухсторонняя связь объект-ссылка(ссылки), то есть ссылка автоматически начинает вести в ноль.
...(потом еще)

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

[Kostia]

И того получился C# )))
По мне так, в C++ на сегодняшний день есть почти все.
Замечу что не хватает такой удобной штуки как delegate в C#. Уж очень не удобно реализовывать ссылки на методы классов, особенно когда методы разных классов имеют одинаковые сигнатуры, то тут одним typedef не обойтись, но хотелось бы.

И вообще хочу чтобы в C++ был тип типа =))) Ну т.е.
Type t(int);
t i = 0;
И я был бы счастлив )))

[_-Re@l-_]

И вообще хочу чтобы в C++ был тип типа =))) Ну т.е.

ЭЭЭ? А что мешает...

typedef int Type;

Или

int b;
decltype(b) a;

[the_deer_one]

Пепел Феникса

то есть на моем компиле можно будет все так же писать С++ программы.

То-то фичи новых стандартов c++ в компиляторы годами не могут добавить. Был 0х, его всё не осиливают и не осиливают. И комитет его взял и переименовали в 11x.

[Пепел Феникса]

И того получился C# )))

шарп не компилируется в нативный код.

[pu4koff]

Сообщение от Пепел Феникса

шарп не компилируется в нативный код.

Зато D компилируется