Здравствуйте, uw, Вы писали:
uw>Лично я не видел ни одного open-source парсера С++ (написанного на C++) и поддерживающего хотя бы парсинг на уровне сравнимом с наиболее адекватными компиляторами.
А качество ОпенС++ ты хорошо изучил?
uw> До следующей фазы компиляции у их разработчиков руки просто не дошли. Основные усилия ушли на парсинг. В OpenC++ парсер рукописный recursive descent + backtracking,
Кстати, R# парсится почти так же, только вместо дебильного ручного парсинга мы взяли коку с возможностью ручного заглядывания вперд (вместо открутки).
uw> для Elsa
А можно ссылку?
uw>был специально написан смешанный generalised lr / lr генератор парсеров, FOG парсит суперсет грамматики C++, а затем уже устраняет неоднозначности.
В шарпе похожие проблемы решаются просто вставкой семантических правил прямо в код парсера. Правда в Шарпе разработчики языка позаботились об том, что бы эти проверки были максимально простыми и не приводили бы к зависимостям разных частей АСТ.
uw>Вся эта работа была проделана ими зря !?
Возможно умнее было бы взять Antlr или CocoR. Правда парсить С++ на Шарпе, Яве или Обероне было бы просто унизительно.
uw>А что касается всего тобой перечисленного самое трудное это увязать правила перегрузки и неявные преобразования, без которых можно и нужно было бы обойтись,
+10
uw> равно как и от других артефактов оставшихся либо по наследству от C, либо превнесенных по ходу разработки.
+20
Именно поэтому я счел, что ОпенС++ хотя и отражает моим задачам, но не подходит. Ведь гнилая основа в итоге не может привести к проблемам.
uw>Самая главная проблема C++ — это нестройность всей концепции языка.
Я бы сказал, слишком большому количеству компромисов портящих язык.
uw> В основе языка несколько фундаментальных правил и тысячи и тысячи исключений из этих правил.
+1 Да уж. Я бы только назвал бы это не исключениями, а подробностями. Чтобы объяснить примитивную вещь вроде процесса вызва конструктора нужно рассказать столько интересного...
uw> Я думаю язык бы серьезно выиграл даже от того, что появилось бы некое более чистое и красивое подмножество.
Согласен. Я вот таким считаю C#. Этот язык мне как раз и нравится, за концептуальную стройность. Минимум компромисов и лишних особенностей.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, uw, Вы писали:
uw>В частности все "фичи" C# скорее относятся к runtime-environment, чем к языку.
Мягко говоря — это не так.
uw> Скорее нужно обобщить и улучшить compile-time возможности языка,
Вот тут согласен если под "compile-time возможности" понимать некую подсистему метапрограммирования.
uw> попутно выкинув из него все маргинальные элементы
Можно их список?
uw> и основательно переработав синтаксис.
И список переработки. Ну, хотя бы в общих чертах.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Про неявные преобразования уже Шахтёр ответил.
Фигово ответил.
A> А битовые поля.... Извини, но современный язык должен позволять взаимодействовать с окружающей средой.
Кстати, я тоже не вижу каких-то недостатков в битовых полях. Иногда вещь очень удобная. Хотя и заменимая с помощью разных BitArray-ев и ООП. В общем, если с битами возиться не часто, то битовые поля не очень нужы. Но хуже от них не было бы.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
Ш>Вот простейший пример. Ш>
Ш>int array[100];
Ш>int *p=...; // указывает на элемент array
Ш>size_t index=p-array; // в это строчке -- неявное преобразование
Ш>
Ш>Если отменить неявные преобразования, ...
... и ввести в язык полноценное понятие массива как объекта первого класса...
Ш>то их придётся писать явно, как в этом и миллионе подобных случаев. Ни надёжности, ни читабельности это не прибавит, читабельности и лаконичности скорее отнимет. Оно надо?
... то к указателям вообще не прийдется притрагиваться в 99% случаев. Читабельность кода при этом улучшается во много раз.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Пока одни ругают Си++, другие на нём пишут и зарабатывают этим деньги. A>>Я не злой — пусть ругают... VD>Странный агрумент. Типа на других языках не пишут? Или за это деньги не платят?
Типа утверждать что все кто пишет на Си++ грубоко ошибаются в своём выборе, это на самом деле глубоко ошибаться самому.
Здравствуйте, VladD2, Вы писали:
A>>Про неявные преобразования уже Шахтёр ответил. VD>Фигово ответил.
ОК, вот тебе мой ответ.
class A
{
};
class B : public A
{
}
B * pb = new B;
A * pa = pb; // пытаются заменить на A * pa = (A *)pb;, что ИМХО никому не нужноdelete pb; // а то сейчас опять про меморилик вспомнят :)
Насчёт необходимости перегрузки функций/операторов объяснять или согласишься что она нужна?
Здравствуйте, adontz, Вы писали:
A>ОК, вот тебе мой ответ.
A>
A>class A
A> {
A> };
A>class B : public A
A> {
A> }
A>B * pb = new B;
A>A * pa = pb; // пытаются заменить на A * pa = (A *)pb;, что ИМХО никому не нужно
A>delete pb; // а то сейчас опять про меморилик вспомнят :)
A>
A>Насчёт необходимости перегрузки функций/операторов объяснять или согласишься что она нужна?
Извини, но это тоже фиговый ответ. Приведение к базовому типу — это всегда безопасная операция, если язык спроектирован без компромисов. В подобных случаях ты и в том же C# обойдешся без явного приведения. Тут проблема в другом. Она в том, что С++ плюет на безопасность ради экономии 4 байт на объект. Ведь по хорошему такой код не должен был бы скомпилироваться без наличия виртуального деструктора.
А вот случай продемонстрированный Шахтером опасен именно сам. И подобные приведения по хорошому не только явно делать нельзя, но и вообще можно разрешать тольков специальном опасном контексте.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Типа утверждать что все кто пишет на Си++ грубоко ошибаются в своём выборе, это на самом деле глубоко ошибаться самому.
Думащь отвечать вопросом на вопрос — это нормально?
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
Tom>Чем больше будут ругать С++, тем меньше новичков будет на нём писать, и тем больше новичков будет писать на .NET, Java, и тем больше будет моя ЗП в связи с грядущим голодом С++ программистов.
I talked to John Lykos at one of the conferences, and he told me that he would pay big bucks for a tool that would be able to tell what header files must be included in a given file.
Когда я занимался портированием прог, я мечтал о таком инструменте каждый день
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, VladD2, Вы писали:
VD>>Ведь по хорошему такой код не должен был бы скомпилироваться без наличия виртуального деструктора.
J>Это по какому это хорошему мне запрещается создавать неполиморфные иерархии без виртуального деструктора? J>Вот спасибо...
Здравствуйте, jazzer, Вы писали:
J>За минус спасибо, конечно, а аргументы будут?
class A
{
};
class B : public A
{
}
B * pb = new B;
A * pa = pb; // пытаются заменить на A * pa = (A *)pb;, что ИМХО никому не нужноdelete pb; // а то сейчас опять про меморилик вспомнят :)
В один "прекрасный" день кто-нибудь другой (или ты сам) напишет delete pa; вместо delete pb;
В данном случае это маловероятно, конечно. А вот если создание объекта и его удаление будут разнесены в разные места проги — запросто.
Wish you happy debugging
Только не надо кричать "да я! да я никогда!" и бить себя пяткой в грудь. Все когда-нибудь ошибаются...
Здравствуйте, Tom, Вы писали:
Tom>Чем больше будут ругать С++, тем меньше новичков будет на нём писать, и тем больше новичков будет писать на .NET, Java, и тем больше будет моя ЗП в связи с грядущим голодом С++ программистов.
Страшно подумать, какие деньги зашибают программисты на Cobol.
Здравствуйте, Дарней, Вы писали:
Д>В один "прекрасный" день кто-нибудь другой (или ты сам) напишет delete pa; вместо delete pb; Д>В данном случае это маловероятно, конечно. А вот если создание объекта и его удаление будут разнесены в разные места проги — запросто. Д>Wish you happy debugging ;) Д>Только не надо кричать "да я! да я никогда!" и бить себя пяткой в грудь. Все когда-нибудь ошибаются... :xz:
Прошу прощения, но это аргумент из серии "Давайте запретим пользоваться указателями, потому что рано или поздно кто-нть поломает память, потому что все когда-нибудь ошибаются".
Я действительно никогда не писал ничего не удалял таким образом.
Единственный случай, когда ко мне приходит указатель на базовый класс, который я должен удалить — это когда этот указатель вернулся из фабрики полиморфных объектов, но в таком случае все и так полиморфное.
Здравствуйте, jazzer, Вы писали:
J>Прошу прощения, но это аргумент из серии "Давайте запретим пользоваться указателями, потому что рано или поздно кто-нть поломает память, потому что все когда-нибудь ошибаются".
Ты всё правильно понял
J>Я действительно никогда не писал ничего не удалял таким образом.
Если ты работаешь один, и работаешь постоянно над одним или несколькими проектами — тогда на это можно полагаться. Иначе — ошибки такого рода обязательно возникнут.
Здравствуйте, jazzer, Вы писали: J>Прошу прощения, но это аргумент из серии "Давайте запретим пользоваться указателями, потому что рано или поздно кто-нть поломает память, потому что все когда-нибудь ошибаются".
А что, есть какие-то возражения против этого аргумента? Пока что среды, запретившие пользоваться указателями, демонстрируют сплошные преимущества и никаких недостатков.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, jazzer, Вы писали:
J>>Прошу прощения, но это аргумент из серии "Давайте запретим пользоваться указателями, потому что рано или поздно кто-нть поломает память, потому что все когда-нибудь ошибаются".
Д>Ты всё правильно понял ;)
J>>Я действительно никогда не писал ничего не удалял таким образом.
Д>Если ты работаешь один, и работаешь постоянно над одним или несколькими проектами — тогда на это можно полагаться. Иначе — ошибки такого рода обязательно возникнут.
Последние лет 8 я работаю только в команде.
Такие вещи в реальной жизни случаются очень редко.
Потому что действительно, если ты разрабатываешь проект и глубоко его знаешь, ты знаешь, где у тебя какие указатели, где память выделяется и где и как ее можно уничтожать. Т.е. здесь проблемы нет.
Если же, наоборот, тебя бросают в горячий проект быстро сделать какой-либо фикс в существующем коде, то вероятность того, что тебе потребуется при таком фиксе удалить пришедший извне указатель при условии того, что в функции, которую ты меняешь, этот указатель не удаляется — 1%. И если мне вдруг (?) взбредет в голову, что я в функции должен удалить указатель — уж на этот случай я приложу все усилия для выяснения происхождения этого указателя. А то ведь так можно и удалить статическую или стековую переменную, не то что деструктор не проверить...
