LINUX.ORG.RU

GDB 7.2

 ,


0

1

В новом релизе GNU Debugger:

  • добавлена поддержка для языка D;
  • расширена поддержка для C++ (поддержка ADL, операторов определяемых пользователем, статических константных членов класса);
  • улучшена поддержка Python (доступ к breakpoints, symbols, symbol tables, program spaces, inferiors, threads и frame's code blocks);
  • улучшения для точек трассировки (поддержка реконструкции после отсоединения, поддержка статических точек, поддержка в GDBServer);
  • поддержка новых платформ: ARM Symbian (arm-*-symbianelf*) и поддержка 64 битной Windows в GDBServer;
  • а также много других значимых улучшений, о которых можно прочитать в полном анонсе релиза.

>>> сайт проекта

★★★★★

Проверено: mono ()
Последнее исправление: hibou (всего исправлений: 1)
Ответ на: комментарий от naryl

> Видим просто образцовый случай Blub Paradox'а.

Во-первых, ваш ответ не имеет отношения к моему вопросу.

Во-вторых, обсуждать Лисп в контексте идей языков Си и Си-плюс-плюс нет смысла. Лисп это функциональный язык, а в большинстве функциональных языков модель памяти не соответствует реальному железу. Больше всего это подходит для кандидатских диссертаций и студенческих работ, хотя промышленные программы с такой моделью памяти тоже можно писать. А в Си-плюс-плюс есть только ограниченные элементы функционального программирования. Только те, которые соответствуют аппаратной модели памяти.

В третьих, Лисп имеет очень ограниченный синтаксис и приходится ориентироваться на семантику. Для большинства программистов это намного труднее, чем ориентироваться на синтаксис. Именно по этой причине (в первую очередь) Си-плюс-плюс считается сложнее, чем Си. И по этой же причине язык Лисп мало используется на практике по сравнению с Си, Java, Бейсиком.

anonymous
()
Ответ на: комментарий от annulen

>> решение сделать все функции виртуальными по умолчанию ничем не лучше «плюсового» решения

как в Яве же.

Да, это я и сам сразу понял.

Поведение виртуальных функций более очевидно для былокодера.

Неужели? Обоснуйте. Кто вам сказал, обнаружить ошибку из-за наличия невиртуальной функции, которую случайно забыли сделать виртуальной, проще для былокодера, чем ошибку из-за отсутствия виртуальной функции у потомка (при наличии у родителя), которую просто забыли написать.

anonymous
()
Ответ на: комментарий от anonymous

чтобы дописать нужную функцию, необязательно знать, в чем разница виртуальной и невиртуальной :)

annulen ★★★★★
()
Ответ на: комментарий от naryl

Лично я их игнорирую потому, что их синтаксис уж больно аскетичен/экзотичен, а возможности все в принципе есть, но реально их надо реализовывать самому. То же ООП - явный пример. Плюс, я уже «испорчен» с-подобными языками. И, разумеется, «as fast as C» (и практически так же не прожорлив по памяти) роль играет. Плюс для меня удобнее, когда функциональные возможности вкладываются в имеративный каркас, а не наоборот.

anonymous
()
Ответ на: комментарий от anonymous

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

Что касается finally - в D есть дух плюсво в том смысле, что не заставляют что-то делать только одним способом. Хочешь - используй стековые классы и RAII. Хочешь используй дишные скопы. Хочешь - финалли. В принципе, на сайте есть статья, где описано, когда что луче применять.

С решением сделать все функции виртуальными тоже как раз всё ясно - автор счёл это деталью реализации (и не он первый, кстати - хоть java вспомнить). Где надо, компилятор соптимизирует вызов.

anonymous
()
Ответ на: комментарий от naryl

Добавьте pure-функции из D2 и всю возможную с их введением чистую функциональщину, где надо

anonymous
()
Ответ на: комментарий от annulen

> чтобы дописать нужную функцию, необязательно знать, в чем разница виртуальной и невиртуальной :)

Сначала надо ещё понять, что дописывание необходимо. Кто скажет это вашему быдлокодеру? Компилятор языка Ди не скажет - он просто не может считать это ошибкой. А компилятор Си-плюс-плюс вполне может ругнуться, если невиртуальная функция «перекрыта».

Кстати, о птичк... в смысле о быдлокодерах. Если уже упрощать язык, то надо было в языке Ди некоторые проблемы языка Си решить. Тот же приоритет операторов в Си был принят исходя из совместимости с языком Би. И получилось не всегда оптимально. Например, в выражении (a&mask) == 0 легко забыть скобки. Кроме того && и || было бы проще писать в виде and и or. Это немного упростило бы внешний вид сложных выражений. Да и тихое падение через конструкцию switch-case для новичков лучше отменить.

anonymous
()
Ответ на: комментарий от anonymous

>> Например, наличие ключевого слова finally ведёт к плохому стилю программирования,

без этой парадигмы невозможно представить например дотнет

kto_tama ★★★★★
()
Ответ на: комментарий от anonymous

> компилятор Си-плюс-плюс вполне может ругнуться, если невиртуальная функция «перекрыта»

Это его надо специально попросить, наверно. Потому что лично я не вижу причины ругаться, если перекрыта невиртуальная функция. мало ли, что именно мне не понравилось в реализации какого-то объекта — это ещё не повод переписывать его полностью, вместо переписывания одной функции.

name_no ★★
()
Ответ на: комментарий от anonymous

Насколько я помню, в D у структур методы не виртуальные, кстати. Но основная суть - в том, что писание явное «virtual» ничего не даёт. D-компилятор имеет достаточно информации для принятия кучи оптимизирущих решений - собственно, это был один критериев разработки языка. И отлично оптимизирует выиртуальные функции. Ну а что касаетсяоверхеда на Vtbl - вы меня повеселили. Такая жесть разве что в суровом эмбеде может потребоваться.

anonymous
()
Ответ на: комментарий от anonymous

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

А мужики из инвестмент банкинга и не знали, что их функциональные языки годятся для диссеров и, может быть, на них еще что-то можно накропать Близость к железу это неплохо. Но это одна из причин наличия синтаксического мусора в сях.

anonymous
()
Ответ на: комментарий от anonymous

>Например, в выражении (a&mask) == 0 легко забыть скобки.

побитовые операции? быдлокодерам?

Кроме того && и || было бы проще писать в виде and и or

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

Да и тихое падение через конструкцию switch-case для новичков лучше отменить.

Это да. Но тогда нужен красивый способ назначить один блок нескольким вариантам

annulen ★★★★★
()
Ответ на: комментарий от anonymous

> Плюс для меня удобнее, когда функциональные возможности вкладываются в имеративный каркас, а не наоборот.

Мсье любитель ходить на костылях, сделанных из бетона. Понимаю.

anonymous
()
Ответ на: комментарий от anonymous

>D-компилятор имеет достаточно информации для принятия кучи оптимизирущих решений - собственно, это был один критериев разработки языка.

не имеет, а должени иметь - в результате разработка компилятора еще сложнее, чем для плюсов

annulen ★★★★★
()
Ответ на: комментарий от anonymous

> кстати - хоть java вспомнить). Где надо, компилятор соптимизирует вызов.

Пи...ц. Во-первых, Java это совсем другой язык, а не диалект Си-плюс-плюс. В него и рекламных денег впихнули много. Бьярне Строуструп однажды сказал: «Некоторые рекламы Java стоят больше, чем весь бюджет Си-плюс-плюс за всё время развития». Java построена на совсем других принципах.

Во-вторых, Уолтер Брайт мотивирует своё решение не производительностью, а борьбой со случайными ошибками. Я на это уже отвечал в сообщении выше anonymous (06.09.2010 14:06:55).

компилятор Си-плюс-плюс вполне может ругнуться, если невиртуальная функция «перекрыта»

Это его надо специально попросить, наверно.

Ваш не умеет? Ну так сами напишите lint-подобный инструмент для этого. Фишка в том, что в языке Ди такое вообще невозможно (описанная мною ситуация отсутствия функции считается нормальной).

anonymous
()
Ответ на: комментарий от anonymous

> Где надо, компилятор соптимизирует вызов.

как показывает практика, если нужна реальная оптимизация, лучше придерживаться концепции «компилятор - дурак» :)

annulen ★★★★★
()
Ответ на: комментарий от annulen

> как показывает практика, если нужна реальная оптимизация, лучше придерживаться концепции «компилятор - дурак» :)

Торвальдс, помню, громко ругался, когда компилятор с ним в этом не согласился.

name_no ★★
()
Ответ на: комментарий от annulen

> > Кроме того && и || было бы проще писать в виде and и or

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

А вы почитайте историю языка Си в изложении его же автора. Он там пишет, что главной причиной было желание упростить плавный перенос кода из языка Би. И где сей час этот язык Би? Стоило ли ради него разные вещи обозначать похожим способом? Сейчас тот же аргумент совместимости можно привести. И так бесконечно. Но тогда зачем вообще огород городить.

Да и тихое падение через конструкцию switch-case для новичков лучше отменить.

Но тогда нужен красивый способ назначить один блок нескольким вариантам

Ну, «назначить один блок нескольким вариантам» это отдельный вопрос. Причём тут єто? Может имелось ввиду частичное совпадение нескольких вариантов. Тогда это performance hack. Такие вещи нельзя делать красивыми (страшные вещи должны и выглядеть страшно). Но при сильном желании можно просто явное ключевое слово для этого добавить. Главное чтобы случайно (по недосмотру) тихих падений не было.

anonymous
()
Ответ на: комментарий от anonymous

>Может имелось ввиду частичное совпадение нескольких вариантов

полное тоже бывает

annulen ★★★★★
()
Ответ на: комментарий от annulen

Нет. Компилятор много проще. D специально проектировался с учетом простоты компиляции. На сайте довольно много объяснений, что та или иная фича приводит к упрощению компиляции в сравнении с плюсами, что отлично подтверждается, к примеру, скоростью компиляции.

anonymous
()
Ответ на: комментарий от anonymous

Вот что он пишет: Virtual functions are functions that are called indirectly through a function pointer table, called a vtbl[], rather than directly. All non-static non-private non-template member functions are virtual. This may sound inefficient, but since the D compiler knows all of the class hierarchy when generating code, all functions that are not overridden can be optimized to be non-virtual. In fact, since C++ programmers tend to «when in doubt, make it virtual», the D way of «make it virtual unless we can prove it can be made non-virtual» results, on average, in many more direct function calls. It also results in fewer bugs caused by not declaring a function virtual that gets overridden.

То есть основная причина - что решение о виртуальности лучше переложить на компилятор, а уже побочная - fewer bugs.

anonymous
()
Ответ на: комментарий от anonymous

может нам всем просто попробовать его использовать хотя бы с месяц, а потом порассуждать :) Да и книга шаблонного маньяка уже доступна на рутрэкере.

Vernat ★★
()
Ответ на: комментарий от annulen

Смотря какой язык, вообще-то. Для плюсов - так и есть, уж слишком язык сложен. Если хотите гарантированно невиртуальные члены - берите struct.

anonymous
()
Ответ на: комментарий от anonymous

C-styly switch - это уже такая классика, что не знать её, мне кажется, уже невозможно. Зачем путать программистов? Хотя, в принципе, можно было бы добавить альтернативный switch-оператор с другим именем и логикой. Было бы вполне в стиле D, с его приоритетом возможностей.

anonymous
()
Ответ на: комментарий от annulen

Так далеко не все всем нужно ООП и тем более полиморфизм. А D как системный язык позиционируется, вообще-то, и как язык, который не ограничивает програмиста (с этим к яве и Go), а даёт возможности.

crazy_alex
()
Ответ на: комментарий от anonymous

> Во-первых, ваш ответ не имеет отношения к моему вопросу.

Имеет.

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


Я и не обсуждал. Blub Paradox наблюдается в людях, а не языках.

Лисп это функциональный язык


Нет, не функциональный.

naryl ★★★★★
()
Ответ на: комментарий от annulen

> не имеет, а должени иметь - в результате разработка компилятора еще сложнее, чем для плюсов

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

naryl ★★★★★
()
Ответ на: комментарий от naryl

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

нет, я просто считаю, что глупо целиком полагаться на ум компилятора

annulen ★★★★★
()
Ответ на: комментарий от tailgunner

>Как такое вообще возможно?

ну если не хранить модули в динамических библиотеках (т.е. готовых бинарях), то что мешает на момент... ммм, «окончательной компиляции» конечной программы, скажем так, «знать» всю «class hierarchy»?

P.S. Внутренностей D не знаю

P.P.S. Понятно, что в этом случае все «готовые» модули должны храниться в виде некоего AST-а, как-то так... =)

yyk ★★★★★
()
Ответ на: комментарий от tailgunner

ну да, «классические статические библиотеки» тоже не годятся

yyk ★★★★★
()

> добавлена поддержка для языка D;

Не может не радовать. Раньше с D (компилятор ldc) работало довольно таки криво.

Deleted
()
Ответ на: комментарий от namezys

GDB 6.8-debian. KDBG как фронтенд. Показать скрины?

Deleted
()
Ответ на: комментарий от anonymous

> Вот только когда уже D2 выйдет, кто б знал...

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

Deleted
()
Ответ на: комментарий от tailgunner

>> D compiler knows all of the class hierarchy when generating code

Как такое вообще возможно?

Действительно не ясно как для AOT компилятора такое возможно. Он по идее должен рассчитывать на самый плохой случай, когда в runtime будут загружены классы, переопределяющие виртуальные функции.

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

kamre ★★★
()
Ответ на: комментарий от annulen

Так ведь какой-то некромант не так давно снова взялся за GDC. Хотя LDC по-прежнему рулит.

Deleted
()
Ответ на: комментарий от AVATAR

> Для D второго уже есть компиляторы?

DMD, и, говорят, экспериментальная поддержка есть в ldc (хотя сам не видел).

Deleted
()
Ответ на: комментарий от anonymous

> Например, наличие ключевого слова finally ведёт к плохому стилю программирования

Каким образом?

решение сделать все функции виртуальными по умолчанию ничем не лучше «плюсового» решения


Что имеется ввиду под «плюсовым» решением?

Deleted
()
Ответ на: комментарий от kamre

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

в AOT нет загрузки левых классов в рантайме

annulen ★★★★★
()
Ответ на: комментарий от anonymous

> А в случае языка Ди ещё и отклоняются от основных идей языка Си-плюс-плюс в худшую сторону без оснований.

1. С каких пор D - диалект плюсов?
2. Почему D должен следовать основным идеям плюсов?

Deleted
()
Ответ на: комментарий от Reset

>интересно когда в него добавят поддержку stl

И Qt

anonymous
()
Ответ на: комментарий от annulen

> Препроцессор жалко конечно)

В 90% случаев препроцессор нужен для создания кроссплатформенного кода, в D для этого свои средства.

Deleted
()
Ответ на: комментарий от anonymous

>Компилятор много проще. D специально проектировался с учетом простоты компиляции.

поверхностный анализ литературы показал, что перед этим компания Digital Mars производила компилятор C++, отличавшийся весьма посредственной оптимизацией. Значит, решили упростить задачу, подогнав язык под свои возможности :)

annulen ★★★★★
()
Ответ на: комментарий от Deleted

>В 90% случаев препроцессор нужен для создания кроссплатформенного кода

я бы так не сказал, есть еще потребность переключения версий кода при компиляции, чтобы не выносить проверку условий в рантайм

annulen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.