17.10.2012 01:57, Sciko Good пишет: > 16 октября 2012 г., 22:22 пользователь Alexander Danilov > <alexander.a.dani...@gmail.com> написал: >> On 16.10.2012 22:06, "Артём Н." wrote: >> Да какая разница, я на С++ с шаблонами такое видел, что после этого всякого, >> утверждающего что C++ - это просто, а Haskell - это сложно, считаю умственно >> неполноценным родственником Джорджа Буша младшего, на котором природа не то, >> что отдохнула, она даже и не напрягалась. > +1 Считаю лучшим способом агитации против C++ дать прочитать книгу > Александреску, а потом учебник Lisp или Haskell. Я не агитирую "за". Есть плюсы в C++. Минусов больше, чем два.
> 16 октября 2012 г., 22:27 пользователь Alexander Galanin > <a...@galanin.nnov.ru> написал: >> При правке из отладчика рассматриваемый контекст ограничен одной >> функцией, потому годится для совсем очевидных ошибок. В других же >> случаях решает ошибку долгая медитация над кодом, по сравнению с которой >> 10 секунд на запуск gdb роли не играют. > Буквально вчера потратил полчаса на поиск ошибки возникающей очень > редко. И это при том, что я даже в C стараюсь писать исключительно > чистые (в смысле ФП) функции. Но пока я эту функцию локализовал и > медитировал над казалось бы уже 100 раз выверенным кодом... Какая ошибка? А средства автоматизации для отлова есть? > 16 октября 2012 г., 22:55 пользователь "Артём Н." <artio...@yandex.ru> > написал: >> 16.10.2012 22:27, Alexander Galanin пишет: >>> On Tue, 16 Oct 2012 21:53:38 +0400 >>> "Артём Н." <artio...@yandex.ru> wrote: >>>> Мне надо: >>>> 1. Написать. Удобно, быстро с отступами и подстановками. Создать интерфейс. >>> Хороший текстовый редактор. А их всего два. >> Вероятно. >> Тогда такой вопрос. >> Есть ли в Vim подстановка блоков кода: я пишу for, а весь цикл со скобками и >> переменной внутри мне подставляется автоматически? > Юзайте clang_comlete Плагин? >> Насчёт двух, вы утрируете. Scite и прочее? > Даже близко не стоит. Помню, в Scite много чего было, включая регэкспы, подсветки и дополнения. Он, конечно, не так наворочен, как Vim (в котором мне ещё разбираться и разбираться), но весьма серьёзный редактор. Помнится был Tea (и ещё спец. редакторы для HTML, например), да и Emacs далеко не один есть. >>>> 2. Собрать часть и запустить на разных этапах (не переписывая Makefile, при >>>> добавлении модуля). >> А этот пункт? > Правильно написанный Makefile не требует переписывания в таких случаях. Но его надо писать. И это непросто. Чем плоха автоматизация его создания? >>>> 6. Проверить модуль с разными наборами данных. >>> Unit testing. >> Само собой. >> И в IDE. Абсолютно тот же самый. >> Разница лишь в том, что вызывает его IDE, а не пользователь. > Да? И как оно догадывается, что нужен unit test? Неужели через astral.dll? В плане того, что есть библиотеки, встроенные в IDE. :-) И простой интерфейс для модульного тестирования. Я не разбирался с этим, если честно, но видел пункт, что оно есть. >> И управляет им IDE. > Управлять юнит-тестом? Это что-то новенькое! А на фига? Вызовом тестов, созданием отладочной версии, созданием релиза. >>>> 3. Попасть на строку, на которой программа вывалилась (именно на ошибку, а >>>> не на >>>> warning). >>> Команда <<:номер-строки>> в виме. При компиляции из самого вима оно >>> перескакивает автоматом. >> Почему-то у меня сейчас в старом Vim (очень старый на старом Linux, но, пока >> что, пишу в нём, поскольку на той машине данные возможно разные получать) он >> перескакивает на всякие варнинги. > Варнинги вообще-то тоже ошибки. И если они так не нравятся, то может > проще их отключить совсем? Например, я передаю константный аргумент функции (указатель на первый элемент списка). В функции инициализирую значение указателя этим аргументом. Старый компилятор орёт, что я могу поменять через этот указатель неизменяемую область памяти. 1. Это ошибка, если я ничего не меняю, а просто хожу по списку и, например, печатаю элементы? 2. Не помню какая pragma это выключает. 3. В идеале хотелось бы окно снизу, в котором отображаются ошибки: кликнул/выбрал - перешёл. Это удобно. >> А мне нужно, чтобы я набрал make, и он остался >> в том же файле. > Это настраивается. Как? >> А ошибку, желательно, вообще открыл в другом окне. > И это тоже. Как? >>>> 5. Пройти дальше на шаг, поменять значения переменных. Изредка посмотреть >>>> дизассемблерный листинг. >>> Это делает gdb. Я даже ставил себе clewn для интеграции оного в vim, но >>> не прижился он у меня из-за неиспользуемости. >> Да, а в IDE, я всё это вижу в том же редакторе. > И сильно это помогает? Правильные ответ: нисколько. Это помогает не переключаться между отладчиком и редактором. И позволяет не "разбрасывать внимание". Это удобно. >>> При правке из отладчика рассматриваемый контекст ограничен одной >>> функцией, потому годится для совсем очевидных ошибок. В других же >>> случаях решает ошибку долгая медитация над кодом, по сравнению с которой >>> 10 секунд на запуск gdb роли не играют. >> Облегчить процесс поиска может watch. Да, в gdb есть, но как-то... > В gdb очень хороший watch. А в комплекте с print, вообще песня. > >> Плюс, есть false-positives, особенно, при использовании глобальных >> переменных, которые содержат адреса. > Глобальные переменные -- глобальное зло. И не факт, что valgrind был не прав. Он был не прав, поскольку писал об утечках, которых быть не могло: я проверил, - всё разрушалось. Там не очень сложная однопоточная программа. Глобальные переменные содержали адреса "баз", которые загружались при запуске и не менялись (метаданные типов сообщений). >> О встроенной в C-Builder тулзе аналогичного назначения воспоминания приятные. > В C-Builder была проверка утечек памяти? О_о Да. В 6-м была точно. Встроенный инструмент, который включался отдельно. >>>> Да, "всё решается так". Но не слишком ли это..? Если бы всё было так >>>> славно и >>>> удобно, вообще, IDE бы придумывали? >>> То есть IDE придумали боги, а нам, простым смертным, надо в него >>> уверовать ибо постичь мы не в состоянии? Или откуда тогда следует >>> желание пользоваться чем-то только из-за того, что оно существует? >> Нет. Т.е. IDE придумали потому, что они были нужны. А нужны они потому, что >> упрощают процесс. > Я знаю только один процесс, который они упрощают: процесс выбора. > Остальное получается очень не очень. Ну а есть лучший вариант? P.S.: Кстати, всё-таки хотелось бы прочитать ваш более ли менее подробный отзыв о Code::Blocks. Что вам не понравилось? Очень заинтересовала эта среда. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/507efb7d.9080...@yandex.ru