Кодирование на C в Linux против Windows.Какой-нибудь адекватный ориентированный на отладку C-ориентированный IDE? - PullRequest
1 голос
/ 27 апреля 2011

У меня возникла проблема с написанием кода на языке c.Моя основная проблема в том, что мне не хватает времени, и в коде, с которым я имею дело, есть много ошибок, которые я должен «устранить» до завтрашнего вечера.

Большая часть проблемы заключается в том, что не существует адекватногоIDE, которая может выполнять отладку в реальном времени, особенно при использовании потоков или порождающих процессов с помощью fork ().Я попробовал Mono, Eclipse и, наконец, NetBeans, и пришел к выводу, что они очень хороши, но не для кодирования на C. Более сложная кривая обучения правильному использованию отладчика командной строки довольно крута.(Как я уже упоминал ранее ... у меня не хватает времени.)

Итак, так как я по профессии разработчик C #, мне было интересно, могу ли я справиться с этим в VS2003 / VS2005 / VS2008 / VS2010.Если я воздержусь от использования системных вызовов, могу ли я это сделать?

Особый интерес представляют методы FILE * descriptor и fread (), fclose (), fseek ().Я знаю, что они являются частью стандартной библиотеки C, но связаны ли они с самой платформой?Одинаковые ли заголовки в Linux и Windows?Как насчет fork () или разделяемой памяти?

Может быть, если я использую VS2010 для одновременной сборки частей компонента (путем имитации ввода и прочего), отладки их, а затем перенесу рабочий код в общий LinuxПроект окажется наиболее полезным?

Любой вклад будет принята с благодарностью.

Ответы [ 3 ]

3 голосов
/ 27 апреля 2011

Большая часть проблемы заключается в том, что не существует адекватной IDE, которая могла бы выполнять отладку в реальном времени, особенно при использовании потоков или порождающих процессов с помощью fork ().

Eclipse CDT , вероятно, будет иметь лучшую общую поддержку для разработки на C / C ++ и интегрированной отладки.

Обратите внимание, что многопоточная и многопроцессорная отладка могут быть трудными в лучшие времена. На этом этапе было бы целесообразно инвестировать в хорошую структуру ведения журналов и, возможно, более полезно, чем полагаться на отладчик. Есть из чего выбирать - взгляните на Log4C ++ и так далее. Даже printf в крайнем случае может быть неоценимым.

Итак, поскольку я по профессии разработчик C #, мне было интересно, смогу ли я осуществить это в VS2003 / VS2005 / VS2008 / VS2010. Если я воздержусь от использования системных вызовов, могу ли я это сделать?

Если вы позаботитесь о том, чтобы использовать только переносимые вызовы, а не API-интерфейсы, специфичные для Win32, все должно быть в порядке. Кроме того, существует много библиотек (для библиотек C ++, таких как Boost ++ , которые предоставляют богатый набор функций, которые работают одинаково в Windows, Linux и других.

Особый интерес представляют методы FILE * descriptor и fread (), fclose (), fseek (). Я знаю, что они являются частью стандартной библиотеки C, но связаны ли они с самой платформой? Одинаковые ли заголовки в Linux и Windows? Как насчет fork () или разделяемой памяти?

Да, функции файлового ввода-вывода, о которых вы упоминаете, находятся в <stdio.h> и являются частью переносной стандартной библиотеки C. Они работают практически одинаково в Windows и Linux и не привязаны к конкретной платформе.

Однако fork() и функции общей памяти shmget() - это функции POSIX, доступные на * nix-платформах, но не встроенные в Windows. Проект Cygwin предоставляет реализации этих функций в библиотеке для упрощения переноса.

Если вы используете C ++, Boost ++ предоставит вам переносимые версии всех этих вызовов системного уровня.

Может быть, если я использую VS2010 для одновременной сборки частей компонента (путем имитации входных данных и прочего), отладки их и последующей миграции рабочего кода в общем проекте Linux, то это окажется наиболее полезным?

Вы, конечно, могли бы сделать это. Просто помните, что Visual Studio имеет тенденцию вести вас по пути Win32, и вы должны быть бдительными, чтобы не начинать использовать непереносимые функции. К счастью, ссылка на библиотеку MSDN дает вам информацию о совместимости. Как правило, использование стандартных вызовов C или POSIX будет переносимым. По моему опыту, на самом деле проще писать на * nix и портировать на Windows, но YMMV.

1 голос
/ 27 апреля 2011

Похоже, я первый, кто порекомендовал Emacs здесь. Вот как работает Emacs. Когда вы устанавливаете его, это просто текстовый редактор с большим количеством расширений (по умолчанию включены отладчик и блокировка шрифта C). Когда вы начнете использовать его и установите пропущенные расширения, он станет не просто редактором. Он очень быстро и легко превращается в IDE, а затем превращается в нечто, способное избежать ОС под одним кадром.

Emacs может занять много времени, чтобы узнать, в то же время, вы можете использовать Visual Slick Edit, если вы не нажали на часть затрат. Я использовал его на обеих платформах и видел, что он хорошо работает с контролем версий, тегами и т. Д.

0 голосов
/ 27 апреля 2011

Возможно Код :: Блоки ?Мне это нравится, и хотя он говорит, что он для C ++, он, конечно, очень хорош и для простого C.

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