Вот я как C# Dev по мимо IDE использую ReSharper, dotPeek, ildasm и ещё такая же кучка вспомогательного ПО которая помогает в работе. А вы что ещё используете по мимо IDE в вашей «сишной» работе ?
PS: Просто очень интересно !
IDE? )))))))))) Из того, что отсутсвует в штатном юнихе — joe (привык я к вордстаровской системе команд) и mc, остальное уже лет 40 особо не меняеться и полностью покрывает все потребности по сабжу. :-)
вот уж не думал что кто то еще джо пользует хехе :)
Не поверишь, но я тоже думал так же ))) Может комьюнити замутить? Сейчас это модно, а тут такой повод :)
Сравнение анализаторов кода: CppCat, Cppcheck, PVS-Studio, Visual Studio: www.viva64.com/ru/b/0241
Как происходило сравнение: www.viva64.com/ru/a/0086
Doxygen, MonoDevelop, Terminal ...
Хотя больше всего помогают всякие самодельные #!/bin/sh
Форматування сирців у всій команді — astyle
Розробка — KDevelop
Профайлінг — valgrind, vtune
Форматування сирців у всій команді — astyleЯ чего-то остановился на uncrustify, а вот с astyle было тяжело получить, что хочу на выходе.
Не знаю яка у вас ОС, але якщо debian/ubuntu, то там в репах попередня версія, а розробники astyle додали багацько гарних штук в останній: astyle.sourceforge.net/notes.html
Я всегда собираю из исходников вещи для персонального пользования. Но в любом случае их поезд ушёл, смысла снова пробовать astyle вроде бы уже и нет, т.к. uncrustify пока может всё, что лично мне нужно.
netbeans, google-breakpad, address-sanitizer, gdb
Використовую Екліпс і СлікЕдіт під Убунтою. Користуюсь CVS, SVN і Mercurial плагінами для Екліпса, cppcheck, Valgrind (memcheck і helgrind), gdb + ddd/eclipse, деколи CodeCollaborator. Для профайлінгу ще *perf з візуалізатором. Для навігації по файловій системі, швидкому перегляду і редагуванню, ssh tftp сесій і т.п. — Krusader.
Все свое написано. Линкер, препроцессор, метакомпилятор, анализатор. Не нравиться некоторые моменты в языке С++ и Си. Много нужно добавить, убрать и переделать.
incredibuild, visualassist, pvs-studio(или cppcheck)
ack это
ack - Kanji code converterили что-то другое?
ack-grep, назва пакета не зовсім відповідає назві команди.
ack медленный. пока наиболее удобное решение — git grep
vim+cscope+find+grep с добавлением gcc и gdb :)
только vim и gdb в command mode — только хардкор! :)
Кто знает, как можно отформатировать/представить дамп памяти/регистров с микроконтроллера (arm7tdmi например), чтобы GDB его понял и показал call-стеки, сожержание переменных и прочие вкусности?
А корка есть? Может просто криво собранный gdb, без эмулятора.
Ну корку-то ОС генерирует? Linux там, или QNX. А если ОС нету, или она экзотическая? Если надо писать обработчик фолта самостоятельно?
Ну тогда сами делайти корку или реализуйте gdb remote protocol на своём устройстве и наслаждайтесь возможностью удалённой отладки.
Интересует возможность отладки post-mortem.
Т.е. нужно самостоятельно рабираться с форматом core-дампа и генерировать его?
Т.е. нужно самостоятельно рабираться с форматом core-дампа и генерировать его?Да там разбираться нечего, почти обычный elf файл. Я серьезно, писал dumper за пару дней.
ddd как надстройку над gdb
использую cgdb, ddd как-то не очень, но и обычный gdb собранный с —enable-tui вполне себе неплох
* Far4ever ) + colorer, mc
* ide: msvs2005, msvs2008, msvs2010 — когда что-то идёт не так под windows, Xcode — если mac
* msbuild — скрипты CI
* cygwin, mingw — первичная верификация кода на соответствие стандарту
* cmake — генерация проектных файлов под конкретную платформу
* wix — инсталяции под windows
* svn, git — контроль версий
ДОУ. Голову неплохо проветривает. В работе это полезно.
AQtime (крутейший для профилирования производительности и утечек)
Visual Assist (раньше)
только под винду? Ещё и проприетарная? Нет уж, совершенно не интересно.
ИМХО, карандаш лучше
А ще стілець та стіл дуже важливі інструменти в роботі програміста.
Вы его так используете?
stackoverflow.com/...microsoft-paint
Ну есть по мимо IDE, то...
компилятор — gcc
контроль версий — svn
отладчик -gdb
профалер-valgrind
А разве CppCheсk вы не используете для статического анализа кода ? Это же удобно ! А тогда какую IDE вы используете ?
Да CppCheck тоже используем, просто он лишь послднее время стал «must use» и к нему много претензий.
На счет IDE, я лично использую KDeveloper, но в отделе преобладает Eclipse.
Ясненько ... А вам встречались проекты где используется чистый «Си» или вы все же склонны работать только с С++ ? И вы можете провести грань где нужно(желательно) использовать чистый Си, а где С++ или в основном везде сейчас используют С++ и в чистом Си нет необходимости ?
Разве что в микроконтроллерах, и то я там сильно не разбирался, просто решил, ежели на чистом С напишу — будет меньше проблем, с перепугу можно сказать
И вы можете провести грань где нужно(желательно) использовать чистый Си, а где С++ или в основном везде сейчас используют С++ и в чистом Си нет необходимости ?Гы, по моему кругу общения кажется, что C++ давно умер и его труп переодически воскрешают для написания какой-нибудь морды на Qt.
То есть в вашем кругу в основном пишут на «Си» ? И если да, то что именно (в общем) или приведите пример ?
Моей благодарности вам не будет придела если ответите, очень интересна эта тема.
То есть в вашем кругу в основном пишут на «Си» ? И если да, то что именно (в общем) или приведите пример ?Часто всё, что хоть каким-то боком касается life critical или mission critical. Как пример, вся начинка для глазного автохирурга написана на С, начиная от управления скальпелем, заканчивая выводом информации на локальный и/или удалённый дисплеи, автомобильная телематика на С, за исключением приложения, которое рендерит карты и обеспечивает GPS навигацию. Чем ниже уровень, для которого пишется софт, тем больше С.
От себя добавлю — ядро линуха и все модули ядра , на чистом С.
Потом, недавно пришлось столкнуться с такой штукой , как питон, так они там всячески стараются упомянуть, что их либы написаны на чистом С и страшно этим гордятся (я так подозреваю с ПХП ситуация аналогична).
в php не все довольны — єкстеншины (плагины) тоже приходится на си писать
В ядре незя на плюсах писать (линуха), также как и плавающей арифметикой. Так что там только Си причем макросизированный ужасный и страшный, мне лично намного проще было на масме читать и понимать код, чем дрова просматривать на линухе, но это конечно же субьективно.
Я под 2.2 ядра писал на С++, всё было нормально. А чего ему быть ненормальным?
Не нашел щас в том ядре где щас колупаюсь на 3.10 ни одного исходника в ядре на спп. Или писал на С++ это тоже так сказать вариант давайте оставим одно название от С++ (все выкинем включая расширения файла даже). Можно ссылочку на какой нить один из исходников на плюсах в ядре, хотя бы отсюда, интересно будет посмотреть что ж там от плюсов то: lxr.free-electrons.com
У Линуса инфаркт с инсультом будет, если кто-то закоммитит С++ код в ядро. Собирайте всё статиком и будет вам щастье. P.S. В те времена бинарные драйвера под Aureal Vortex 8820/8830/8810 были написаны на С++ под 2.2/2.4 ядра.
я чета не пойму, кажись С не поддерживает ООП, как тогда все написанно — процедурным подходом ???
А что такое ООП в С++? Как оно построено?
я не проффесор, просто вдруг (если я правильно понял) оказалось что весь серьезный софт пишется на процедурном подходе. Я себя таким тупым всегда чувствовал что не мог понять ООП.
Попробуйте рассмотреть struct как class только с public members.
я не особо помню С, struct — это как коллеция объектов кажись ? Я на С довольно успешно решал олимпиадные задачи, но потом все начали ООП и я потерял веру в себя )))) А теперь оказывается что это все была попса...
я не особо помню С, struct — это как коллеция объектов кажись ?Просто структура данных, данные, например, могут быть в виде указателей на функцию и вызываться почти так же, как и в C++, единственное, что мультинаследование и таблицу виртуальных функций надо делать руками, но и это несложно. В общем я к чему, было бы желание и работу себе можно облегчить напорядок.
Я вначале выучил С++ по второму тому Страуструпа, а потом только через много лет пришлось учить С89, вот это была пытка. Но с другой стороны это позволяло максимально приблизить С к подобию ООП.
Я не знаю, откуда пошёл этот бред, но многие стьюдент-девелоперы называют ООП виртуальные функции. А-ля: «сделать в классе ООП = определить в классе виртуальные функции».
Повбывав бы.
Мне один умный человек сказал, что реализация полиморфизма в С++ - это виртуальные функции. Он прав?
В первом приближении.
По полочкам вот тут неплохо разложено gaperton.livejournal.com/15121.html
ну розрізняють статичний й динамічний поліморфізм. Динамічний це механізм віртуальних функцій. Статичний це механізм перевантаження функцій та операторів.
плюс темплейти, також варіант статичного поліморфізму.
В Си весь полиморфизм — это void*
Никто не мешает хранить инфу о типе в структурах, а потом ее «кастовать» в нужный тип.
И написать мегабольшую функцию, которая умеет инкрементировать указатель на нужное смещение. И вызывать соответствующие функции.
Клиентский код вызывает одни и те же процедуры. Обработка разных данных имеют одну реализацию.
Мне кажется я сейчас придумал CRT C++ с таблицей виртуальных функций, итераторами, RTTI! :)))
Я ничего не понял, сорри.
Наверное С++ выше моего понимания :-)
процедурный подход и основан на использовании подпрограмм и функций вместо объектов, используется языками
С++ поддерживает ООП и оба подхода: объектно-ориентированный и процедурный
C и С++ разные языки, как Карл Маркс — не муж и жена.
так и я о чем, С- это только процедуры и инклюды.
Вопрос в удобстве использования той или иной парадигмы в контексте конкретного языка программирования. На первой работе был проект где вполне себе было реализовано ООП на С с помощью макросов. Другой вопрос что если что-то ломалось, то там можно было идти вешаться, но в целом все работало.
В моем понимании С и С++ разные, т.к. у них разная стандартная библиотека, плюс у С++ куча «свистелок», т.е. говоришь С++, подразумеваешь STL, boost, tr1 и прочее.
Другой вопрос что если что-то ломалось, то там можно было идти вешаться, но в целом все работало.Интересный подход, иными словами код: write-only или на выброс. Такой можно писать абсолютно на любом языке.
Нет, если ты понимаешь как оно устроено, то все очень просто. Проблема в другом, тогда я был студентом, код писался в году
Это вам просто не повезло с теми кто это все проектировал и писал. На нашем проекте с емуляцией ооп по принципу что описал Майк (через структуры, указатели и т.п.), макросы вообще были забанены через кодинг стайл — все замечательно поддерживалось, быстро и надежно фиксилось по ходу если что-то всплывало. Легко расширялось. Не вижу проблем в принципе, а у вас просто криво реализовали (см. через макросы). А на плюсах тоже можно таким узлом все завязать, что и концов не найдете. Как и на чем угодно. Чем сложнее инструмент — тем туже узлы, то бишь в плюсах узлы подобротнее чем в сях.
я чета не пойму, кажись С не поддерживает ООП, как тогда все написанно — процедурным подходом ???на си вполне можно писать ооп , кроме линуха можно глянуть на winapi и com/dcom
Интересно а как же плюсовые рт-либы, без которых сложно представить настоящий прокаченный цпп-код... его же в ядре то как не было так и не будет, как же тогда все это заработает. У меня все еще большие сомнения что тот цпп код что вы писали настоящий цпп ооп код. А эмуляцию на сях некоторых объектных вещей через структуры с базовым классом (структурой) вначале и допиской оригинальностей дальше мы тоже делали, но цпп-кодом при этом не называли.
Интересно а как же плюсовые рт-либы, без которых сложно представить настоящий прокаченный цпп-кодИспользуй
Хорошо, как работают исключения, если мы используем большой C’шный проект и С++ плагин для этого проекта. Будем ли мы пробрасывать исключения из плагина аж до аналов С’шного проекта или закончим их жизнь на точке экспорта С’шных функций в плагине?
Я не очень хорошо разбираюсь в С++, но в моем понимании исключения это когда можно писать
foo1(); foo2(); foo3()вместо
r = foor1() if (r == E...) .... r = foo2() if (r == E...) .... и тд.Т.е. исключения отлавливать где-то на уровень выше, в вашем случае получается скорее второй подход чем первый.
What happens in Vegas stays in Vegas © Любые исключения не должны выходить за рамки С++ кода, правило простое.
Вам все равно придеться ловить исключения в блоке try и принимать в catch. Иначе их будет обрабатывать ОС. Или unxpected exception callback function.
long jump
в Си есть goto.
Также в Си есть callback функция, которая типа берет на себя исключительные ситуации. Есть ж типа abort() exit() которая позволяет выходить из проги в любой момент.
Еще стоит отметить что exception это относиться не только процессору, но и к ОС. Потому что проц выбрасывает три вида исключений, который должна ловить ОС и сообщаться программе. Исключения выбрасываются в определенный адрес в памяти. И защищены. Они могут настраиваться.
В Си без костылей, без ассемблерных вставок при соответсвующих либах это можно сделать.
Оно то понятно но опять же тот же самый вопрос насколько вы себя ограничивали в плюсовых плюшках. Если не ограничивали, то какого статического монстра вы после этого собрали. Как с этим всем потом в космос (ну или в ядрышко). Это же балласт еще тот. Не, воркэраунды можно на все сделать, это да, но иногда такие костыли мешают потом. Я не удивляюсь что дальше ядра 2.2 не пошло, я уже начал работать с 2.6 и выше и такого пока что не видел.
Я спорю с утверждением, что нельзя собирать модули ядра с С++, а не с тем, что так правильно или неправильно для critical проектов :)
Я как раз занимался этим, в теме разработки ОС. Как писать на С++ для голого железа. Ну try catch throw — можно игнорировать игнорировать. Хотя что я мелю, лонг джамп на catch блок и все, с передачей параметра. Catch это как внутренняя процедура. Теоретически Си и его семья может позволить объявлять классы, процедуры. В D это можно делать. Класс в классе, в методе процедура, а в процедуре еще один класс определяется и объявляется. Хотя в D определение и есть объявление. Идея взята из C# и Java. Ирония в том, что C# брал наработки Java, а Java С++.
исключения реализуются запросто с раскруткой стека.
Выделение памяти — это штука относиться напрямую к ОС. Ну нет в железках такого «А дай мне памяти?». Это конструкция противоречива сам по себе. Можно сделать new delete если ваша програ будет единственной прогой в системе. Тогда это просто.
К тому же new delete можно на стеке построить. Как и локальные переменные. Можно просто сделать зарезервированный буфер фиксированного размера.
Все остальное и так вшивается компилятором. Я специально пропустил ООП, потому что транслировать ООП в машиной код компилятор умеет и так без проблем. И в каждом .exe там свой механизм. Вплоть до таблиц виртуальных методов. А также динамическая типизации. Компилятор и так кладет в код дополнительные данные о типах при динамическом кастовании или полиморфизме. Нет смысла делать это самому.
На C++ спокойно можно писать ядра. Все зависит от компилятора. Дополнительных механизмов внешних не нужно. Если компилятор знает об ограничениях платформы, вплоть до максимального объема RAM, то все абстракции можно перевести на машинный язык под голое железо.
Еще никто не мешает засунуть аналог stdlib, STL.
У ядра тоже есть свои инклуды, либы. И даже вывод в треминал. Если не ошибаюсь это kprintf()
Якраз Symbian OS написана повністю на с++.
Была BeOS ещё. Из маргинальных ос — Syllable.
наверное вы о принтке все таки
lxr.free-electrons.com/...k.c?a=arm#L1676
Так это базовая вещь, хотя вывод можно делать в ядре через фиг знает сколько разных вариантов оберток, различаться будет куда будет перенаправляться вывод и настройками фильтрации уровней. Причем здесь это и такой монстр STL. Принтк реализация уже стандартно в ядре висит и можно с помощью крос референсов посмотреть на нее от версии к версии. СТЛ нет стандартно в ядре. Собрать статически конечно же все можно. но это громадный оверхед. Про прочие оськи я не говорил, а речь шла только о ядре линуха. Там я не видел ЦПП в стандартной сборке или что-бы кто-то туда лил свои модули (дрова) на ЦПП из моих коллег или это было бы описано в книжке-литературе.
Про локальные переменные — они давно уже как хехе распределяются на стеке по умолчанию, даже не знаю можно ли как то по другому но это вроде компилятор делает в любой своей реализации. Со статическими переменными тоже все понятно. Вообще я стараюсь не выделять динамически память когда пишу под ядро. Но если нужно, то конечно что уж тут. Но чрезмерное использование дин. выделения памяти это далекоо не основная особенность ЦПП-ООП. Речь шла о другом.
Останусь при своем. ЦПП в ядре линуха — это инородная материя, делают это только извращенцы (включая студентов, которым охото поигратьсЯ) и люди, которым позарез нужно это (специфические проекты) и при этом люди понимают как внедрить это чудо в ядро чтобы не было проблем (вот например, Майк). Иначе можно легко напороться на то, что алгоритм отрабатывать на обычном юзерспейсе и в ядре будет совершенно по разному и можно будет долго копаться и думать в чем же там дело. Сделать ошибку в ядре и в юзерспейсе может дать совершенно разные последствия.
Вот в проекте сейчас планируется переходить на две оськи параллельно — линух и андроид на одном камне, в этом как мне кажется есть смысл.
Последние несколько вакансий что мне присматривались (и тут в Голландии и в Украине в Харькове) по медицине писались на плюсах (я щас не о гуи а именно о хардварном софте, причем самом критическом для жизни, некоторые при этом умудрялись туда еще и оськи пихать — ужас). Паттерны и прочее, вообщем там плюсы еще и намученные были до полного нехочу. Удивился, но таковы увы современные тенденции, медицина уже давно пишется на плюсах. Хотя видел как проекты мигрировав на плюсы потом откатываются на чистый Си. По поводу телематики смешно, я проработал 4 года в Люксе на автомобильной телематике. 1й проект был действительно на сях с эмуляцией некоторыех ООП вещей. Остальные проекты были уже на плюсах. Дрова — вот то что пишется на Сях (бо иначе никак хаха). Имеется в виду линуховые. Кернел спейс вроде по другому не напишешь.
Авиация тоже давно пишется на плюсах. Но при этом наиболее разумные конторы которые думают о надежности, предсказуемости продукта и жизни своих клиентов (медицина, авиация, авто) пишут на Сях но увы полно и тех, кто тянется за быстро написанным кодом и не важно как быстро он упадет и при каких обстоятельствах. Я принципиально вижу когда критическая область применения, и выбраны плюсы даже не аплаюсь потому что мне будет стремно работать в таком проекте.
Авиация тоже давно пишется на плюсах. Но при этом наиболее разумные конторы которые думают о надежности, предсказуемости продукта и жизни своих клиентов (медицина, авиация, авто) пишут на Сях но увы полно и тех, кто тянется за быстро написанным кодом и не важно как быстро он упадет и при каких обстоятельствах.Если следовать требованиям RTCA/DO-178B, то от С++ останется С и классы. Поэтому в таком С++ особых проблем нет.
Вообщем то не надо заниматься тавтологией. Если выкинуть все что привел и при этом писать на плюсах си-подобные не ООП программы то это и будет си (хоть и файлы с расширением cpp). Имелось в виду что существуют много компаний (и в авиации тоже), которые следуют стандарту ДО и прочие не в полном объеме и используют всю мощь ЦПП. О таких я и говорил. С таких проектов так и прет все недостатки такого выбора.
Имелось в виду что существуют много компаний (и в авиации тоже), которые следуют стандарту ДО и прочие не в полном объеме и используют всю мощь ЦПП.Но наступич час Ч и придётся проходить сертификацию в ДО, которую они не пройдут, НАСА, Боинг, Мартин-Локхид таких контракторов в шею погонит.
Майк опять же, я работал лично на протяжении последнего года на проекте Боинга. Разговаривал со спецами из Сиетла, кто напрямую на боинг работают, у нас эти стандарты да, везде в рамочках и все. Все это вообщем то по большому счету формальность. Сертификацию всего что описал проходится в боинге на ура. Никого в шею не гонят, заключают новые контракты, люди получают за гонокод шарет профит ежегодна в очень кругленьких суммах и все довольны. Так что откуда у вас такой пессимизм. Я давно понял, что теория и практика расходятся. Ваша команда вот сдавала сертификацию на CMMI 5, боинг работает только с теми, кто получил этот ранг, а знаете как проходит сертификация и какое реальное положение вещей. Я год писал доки, требуемые под ДО для боинга и эирбаса (спецификации, тест планы и еще 1001 лабуду, тонны бумаги и мало кода). Я видел много мегатонн бумаги которой писали такие же как я, это хрень полная и никому не нужная, ее даже использовать невозможно. Я перекрестился и ушел с той работы, моя новая мне нравится намного больше, настоящие живые проекты. Да мои доходы упали, боинг за это бумагомарательство платил очень приличные деньги, но это была не работа а каторга. Да деньги важны, но они не все, есть и еще что-то, что важнее в жизни. У каждого оно свое.
В
Тут же вообщем то впаривали такую залипуху, которую было видно буквально с полминуты скоростного пролистывания. И я видел как это все успешно осертификачивалось. Честно без придумок.Может это для прототипирования, потому, что из того, что я вижу и что хоть каким-то боком меня касается, то заказчики из этого списка www.qnx.com/...efense-2013.pdf выставляют очень сильные требования к продукту. Они даже используют особое микроядро, это по большей части не то, что идёт на демо и trial компакт диске. Хотя и классическое микроядро сильно вылизано тоже.
Это серийное осертификаченное изделие поставляемое на борт боинга, это как раз самая настоящая сертификация, которая занимает тучу времени и денег, это процесс, ориентированный больше на процесс, чем на результат.
Кстати по поводу надежности софта. У эирбаса и боинга подходы рознятся. У боинга вероятность фейла любого софтового продукта равно 1 (не важно как покрыто тестами), у эирбаса она может вычисляться. Поэтому у боинга любая система, построенная на софте должна дублироваться железякой, у эирбаса нет. Может поэтому и при сертификации программ на многое закрывают глаза, потому что все равно голяк. Но я видел прощелки в атестованной железяки боингом, банально температурный диапазон компонента не соотв. тому что было записано. Я это лично увидел через 5 мин. после пролистывания доки. Специалисты боинга это пропустили. И на минуточку этих образцов выпущено уже в серии не одна сотня и они все уже давно на борту и летают. Вот так вот. Да формально боинг все равно требует доки согласно ДО (тест планы, акомплишменты и прочее), потому что они должны быть, но софтовый продукт заранее считается ненадежным и должон быть продублирован. Это требование легко можно обойти, абстрагировшись и назвав программный узел черным ящиком с вероятностью отказа от фонаря. После этого этот узел будет рассматриваться как обычная железяка (электроника, механика и т.п.). И насрать.
По поводу бумажных сертификационных драконов — вспомнился веселый скандал с крейсером, который потерял ход из-за зависшей WinNT.
Кто-то ж ее для ВМФ сертифицировал!
И это была 3.5, которая была полной ж по надежности...
Правильно писать — «его страус_труп»!
bash, nano, make, gcc, grep, google...
P.S.
іноді HR присилають дивні таблички та форми у Exel або Word форматі.
тоді рятує LibreOffice
Oleg Yakovlev
chronoman
Oleg Yakovlev
Андрей Карпов
anonymous
Нестор Иванович
Oleksandr Senkovych
Mike Gorchak
Oleksandr Senkovych
Sergei Beloborodov
Sergiy Bachynskyy
Настасий Петрович
Dmytro Sirenko
Настасий Петрович
Petja Ivanov
Mikhail Boiko
Дмитрий Старина
Andrew Ivanov
Anton Mykhailov
Денис Кузьменко
Денис Кузьменко
Andrew Ivanov
Vladyslav Kurmaz
Mikhail Boiko
Alex Fogol
Alex Shevchenko
Sergei Beloborodov
Oleksandr Kolosov
Sergii Voloshyn
ScorpZ Lapshov
ScorpZ Lapshov
Oleksandr Kolosov
NoName
Artem Komisarenko
Gabriel Angelos
Ivan Sorochan
Andriy Oshtuk
Tim Tretyak
flyman
102 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів