Weekly linkdump #180
Сергей ВолошинОпубликовано 19.06.2009 в Ссылки
Интересные ссылки за не неделю:
- Ссылки по C++ от ducoze
-
- Открылся developer.symbian.org . Правда пока только в бете, но уже очень многообещающий ресурс. Множество статей и туториалов, в том числе о PyS60. Все оформлено в виде вики.
- Qt уверенно продвигается на встречу тому же Symbian. инструкция по сборке Qt для S60 5th Edition и пример игры Color Lines смигрированной под Symbian.
- Intellisense в Visual Studio 2010 работает с плюсами подобно динамическим языкам. Семантические ошибки и даже возможные ошибки компиляции подсвечиваются во время редактирования исходников.
- Достаточно интересный блог по шароваре — successfulsoftware.net. Обсуждаются всевозможные вопросы и проблемы создания и распространения своего shareware.
- Ссылки от Скакунова Александра из блога woork.blogspot.com:
- Декілька скрінкастів про Python пропонує переглянути presidentua:
-
- Про створення скрипта, що може зберігати змінні в себе в тілі скрипта. Цікаво для написання маленьких скриптів, в яких корисно б конфігурацію зберігати в собі: Python. Selfchange script. Screencast. Код скрипта.
- Скрінкаст про фрактали, множину Мандельброта, про оптимізацію з модулем Psyco, а також трохи про декоратори. Така собі солянка вийшла. Screencast Python. Рисування і Оптимізація. Код скрипта.
- Ссылка от Александра Краковецкого:
-
- Хорошая подборка ссылок по ASP.NET, AJAX, MVC, VS от Скотта Гутри
- Ссылка от Михаила Сорочана:
(7 голосов, средний: 4.29 из 5)
Загрузка ...Понравилась статья? Подпишись на обновления по RSS/E-mail
Начал смотреть http://vimeo.com/5178598 – было интересно, технический скринкаст на украинском.
Но оказалось просто жуть. Автор очень много “эээээ”-кает и “ааааааа”-кает. Но это ладно. Говорит на суржике
А после “проведемо оптимізацію, згідно з якою зменшимо швидкість виконання в пять раз” (причем два раза повторил), я решил дальше не смотреть.
Питоновские скринкасты – не идеал, но в целом весьма неплохо. Можно поработать над закадровым голосом (м\б сценарий подготовить и какой-то телепромптер?)
“Intellisense в Visual Studio 2010 работает с плюсами подобно динамическим языкам” — у меня несколько вопросов на тему.
1. Что значит “подобно динамическим языкам” в данном контексте? Если бы оно могло работать с питоном подобно статическим языкам, я бы понял это как комплимент (поскольку в статических языках гораздно больше возможностей для выявления ошибок).
2. По поводу того, что оно выводит ошибки компиляции as you type — насколько я понимаю, это то, что какой-нибудь Eclipse с какой-нибудь Java умеет давно. Тут дело в том, что с C++ такое делать намного сложнее, или в чем?
3. Бегло просмотрел статью и так и не понял, какие семантические ошибки оно умеет определять. Пример можно?
2 Роман:
1. Этой фразой я подразумевал фичи вроде “check as you type”. Раньше это было не достижимой мечтой для С++ разработчиков, т.к. для проверки правильности кода необходимо было его компилировать. Возможно я выразился не совсем корректно
2. Действительно, такое давно умеюют Java, C#, Python, etc. Однако надо понимать сложность языка С++, множество различных значений одной и той же конструкции в различных контекстах. При работе к примеру с C# практически вся информация доступна уже при редактировании кода во многом благодаря мета-информации, хранимой в сборках.. В С++ ранее полная информация к примеру обо всех символах в проекте была доступна только после компиляции & линковки, ввиду отсутствия мета информации как таковой. Так что да, это действительно большое достижение
3. Собственно пример есть в статье на первой картинке в самом начале стаьи – там ошибочно создается объект, без передачи параметров конструктору. Также примером может служить присвоение значения переменной, которая не была объявлена. В таком случае, операция будет подсвечена красным цветом.
2. Не понятно, какое различие в языках C++ и C# мешает хранить для C++ ровно ту же метаинформацию, что и для C#?
3. В статически типизированных языках это ошибки синтаксические, не семантические. Их определяет (должен определять) компилятор во время компиляции.
Примеры семантических ошибок: неожиданное вхождение в бесконечный цикл, попытка доступа к “чужому” (или несуществующему) адресному пространству, чтение неинициализированной переменной/памяти.
2. С# и С++ имеют довольно мало общего между собой, за исключением схожего синтаксиса.
3. Фразу на счет отлова семантических ошибок я привел из блога, примеры действительно неудачные. Поиск в гугле действительно не дает пример, какие-именно ошибки будут подсвечиваться. Думаю стоит дождаться релиза.
А мало это сколько? По вопросу согласен с Романом.
Вы хотите пофилософствовать о том, что есть мало и что нет? Если вас интересует сама тема предлагаю вам почитать стандарты обоих языков и типичные их реализации.
Это был иронический ответ на ваш “аргумент”, что типа различия между C и C# мешают хранить метаинформацию. Какие конкретно различия мешали раньше обработать ситуацию, продемонстрированную в самом начале приведенной вами статьи?
:wall
Сборка в C# самоописываемая, т.е. она хранит в себе полный и недвусмысленный набор типов в виде мета-информации. Эта возможность поддерживается также на уровне платформы .NET, которая предоставляет множество facilities вроде reflection. Таким образом, компилятору, IDE и другим утилитам нет нужды делать какие-то вещи из разряда rocket science для реализации check as you type. От IDE требуется всего лишь прочитать мета-данные, связанные со сборкой и сопоставить их с тем, что пишет девелопер. Это фича языка и платформы.
Хранение мета-информации не заложено стандартом языка. С++. DLL и EXE файлы, написанные на С++, не хранят в себе никакой мета-информации, за исключением таблицы экспорта, которая не является стандартизированной между компиляторами и которой вообще может не быть. К тому же, как я уже говорил, в я зыке С++ очень часто встречаются конструкции, которые имеют разный смысл в различных контекстах. Добавьте сюда шаблоны, полная информация о которых становится известной только после компиляции всех точек, где они используются, в результате чего из одного типа получается целый набор. Также можно упомянуть PIMPL. Вам не достаточно видеть точку объявления типа, т.к. в другом месте в том же модуле имя типа может быть использовано совсем по-другому.
Таким образом, ни одна IDE не реализовывала до сих пор подобной функциональности для С++. Обнаружение семантических ошибок в С++ усложняется в разы, по сравнению С# по все тем же причинам.
Исключением является независимый продукт Visual Assist – платный Add-in для Visual Studio. Суть его работы – парсинг всех видимых исходников, построение внутренних таблиц и связей между ними. Далее, на основании собранных данных, эта утилита пытается подсказывать девелоперу места возможных ошибок. Но эффективность ее работы, хоть и очень высока, все таки далека от идеала – довольно много времени занимает пре-парсинг исходников, и зачастую она говорит об ошибке там где ее нет.
Не известено на сколько корректно Visual Studio 10 будет выполнять данные функции, но есть надежда на лучшее.
Если вам из этого объяснения все еще не понятно, почему для мира С++ такая функциональность IDE – открытие, я не знаю чем еще Вам помочь.
Бла бла бла. Тебя спросили, что принципиально мешает IDE хранить метаинформацию для С++ кода?
Никто не говорит о том что бы покрыть абсолютно все кейсы. Я спросил конкретно про пример приведенный в начале статьи. Что мешало его обработать еще лет 10 назад?
Не слишком ли много пафоса? Ты просмотрел все IDE? Мне время от времени приходится накидывать простенький код в QDevelop и эта абсолютно бесплатная и опен сорс IDE умеет подсвечивать ошибки в коде, в том числе она справляется с примером приведенным в начале статьи.
Особо радуют твои трагикомичные заключительные цитаты. Пеши еще!
Вы просто феерически уперты.
Принципиально Вам ничего не должно мешать полететь в космос, но в реале вряд ли ты там когда нибудь побываешь. Такой ответ устраивает? ))
Тем более, я сказал, что есть Visual Assist.
Я не совсем понимаю, что именно вы имеете ввиду под “примером, приведенным в начале статьи”, но QDevelop – узко специальная тулза. Я вроде нигде не говорил, что какие-то специфические моменты С++, тем более приминительно к одной библиотеке, нельзя реализовать.
Линк про студию появился потому что она должна обрабатывать ошибки по всему фронту С++.
Ну а личные наезды оставьте себе.
Как узкоспециализированность QDevelop может рассматриваться как аргумент в этом споре?
Открой статью на которую ты дал ссылку, и посмотри на первый же скриншот.
Там в комментах к статье автор дал перечень фич которые еще не поддерживаются. Ну и поскольку ты явно не делал сравнительного анализа по фичастости с конкурирующими продуктами, то наверное не можешь утверждать что
Более того, в статье как бы не написано как они реализовали обсуждаемую функциональность. Вполне возможно, они просто выдают на выход ошибки компилера.