IID>Тем не менее это не мешает "мясо" библиотеки писать на С++, а наружу выставлять pure-С API. Вон, в винде дофига юзерленда именно так сделано.
Ну это кривизна необыкновенная. Когда два С++ класса общаются между собой на C, и лишены возможностей взимодействовать с использованием возможностей С++. И то, как это сделано в ВинАПИ, кстати, есть тоже кривулина.
Здравствуйте, abdul.zycor, Вы писали:
AZ>Здравствуйте, Menestrel, Вы писали:
M>>Здравствуйте, Ikemefula, Вы писали:
I>>>нет хорошо доступных серьезных инструметов например I>>>1 для рефакторинга, I>>>2 отладки I>>>3 анализа кода
M>>Это ты зря сказал M>>Сейчас тебя загрызать будут
AZ>Между прочим это действительно так, различается очень разработка в студии. AZ>Написав код в студии я сразу же пытаюсь его отлаживать, протрейсить его весь или частично ну если это возможно. А написав код в виме, например трейсить его лишний раз в gdb желание отпадает, ну конечно остается только смотреть логи.
это чуть ли не в последнюю очередь на самом то деле!!!
в первую очередь код который разрабатываешь должен быть покрыт юнит тестами... вот они решают кучу головняка и делают не нужным тупые действия типа пописал чучуть, скомпилячил, пошел трэйсить, нашел фигню, пошел исправлять, & etc -- ну да я в студенчестве тоже так делал... сейчас кроме как с улыбкой это не вспоминаю -- это все от того что программист не уверен в том что пишет... а не уверен в основном от того что не думает, или думает слишком узко ... (мое такое имхо)
второе это просмотр коры... собственно в 90% случаев именно для этого я использую GDB -- какиета мега IDE и прочий гуйный хлам нафиг тут не сдался...
`gdb mybinary core`
bt
вот и все!
зачем вокруг нескольких команд (fr, thr, bt, p, x) делать front endы для меня загадка...
логи приходится сомтреть когда на самом верхнем уровне чегото не так... или допустим клиенты тебе прислали логи твоей проги...
раз уж начал писать в этот thread, не могу не высказаться по другим пунктам...
со средствами рефакторинга как известно есть проблемы -- не раз обсуждалось почему и от чего это так (и в данном контексте оффтопик)...
опять таки скажу с позиции лично моего опыта: ну да несколько не удобно работать, но не архисложно... т.е. даже "не сложно"... ибо большая часть рефакторингов делается руками в редакторе... ну да вместо "одной кнопочки" (точнее меню, диалога, и нажатия Ок) приходится копипакостничать, пользоваться find/replace + regex. А также выручает умение моего редактора пропайпить выделенный текст через любой фильтр (сымсле конвейер, если кто не понял) -- и вот тут всякие IDE с решарперами могут покурить в сторонке... в более сложных случаях на помощь приходят find, grep, sed, xargs, & etc выполняемые из консоли... но это все мелочи по сравнени с тем что сначало приходтся фтыкать в говнокод, потом думать как это улучшить малой кровью и только после этого начать чегото колбасить... вот это я назвал бы полным циклом рефакторинга, а не только последнюю часть связанную с редактированием текста ... дык вот во всем этом цикле сэкономленное время мне кажется не мегасущественным... -- на обед времени тратицо гараздо больше
про отладку уже сказал выше
анализ кода? это о чем? смысле поиск багов без компиляции? навигация по коду? -- не зная что аффтар имел ввиду просто перечислю чем я еще пользуюсь в работе:
ctags -- ну какая-никакая навигация (прикручен в редактор)
lint -- статический анализатор кода... крайне редко пользовался (фактически пару раз когда захотелось проаналайзить откровенно аццкий быдлокод стереть который немедленно было нельзя)... в природе есть еще там какиета подобные тулзы -- но это все для реальных проектов не канает... ошибки обычно более сложные чем они могут находить (если конечно код писали не студенты практиканты)
valgrind -- отдельного представления не требуется я думаю...
strace,truss & etc -- ну тоже все понятно...
все инструменты "хорошо доступны" и крайне серьезные -- не прочитав ман фиг попользуешься в полный рост чтобы
AZ>Не плохо и не хорошо это, просто по другому.
+100500
Здравствуйте, Ikemefula, Вы писали:
AZ>>Вот возникает вопрос почему так, когда с++ современее, удобнее. Есть библиотеки типа boost, stl. I>Есть в с++ нечто, что рождает монстров вроде буста и стл, и благодаря им так и сложилось с серверами.
На самом деле ни буст ни стл не являются необходимым условием написания программ, даже таких хитрых, как промышленный веб-сервер. Ни что не мешает с нуля сделать свои библиотеки с преферансом и гетерами — так как это обычно делают на голом С, типичный пример apache и его apr + apr-util.
AZ>>Какие могут быть обьяснения тому? AZ>>У меня такие: AZ>>Почему пишут на с: AZ>>1. в отладчике gdb приятнее видеть короткий простой код на с
на самом деле gdb довольно хорошо умеет работать и с с++.
AZ>>2. не знают с++, поэтому пишут на с
Возможно. Но тогда скорее всего пишут на "си с классами".
AZ>>3. переносимость под другие платформы, все же мне кажется код на с переносимее чем на с++
Ну, если учесть, что компилятор, который нормально умеет компилировать под разные платформы всего один, и он один и тот же для c и c++ хотя да, некоторые плюсовые плюшки могут где-то не заработать.
AZ>>4. нет инструментов типа, таких как под винду, для рефакторинга и прочее, с инструментами типа gdb, emacs, vim п омоеум сложнее писать на с++
Имхо никакой разницы нет — поддержка этих языков практически одинакова.
I>нет хорошо доступных серьезных инструметов например I>1 для рефакторинга, I>2 отладки I>3 анализа кода
Опять-таки ситуация с С и С++ в этом плане практически одинакова. И она не является препятствием для написания серверов
I>компиляторы между собой слабовато совместимы, собственно это и показывает ущербность языка
И опять-таки это не важно для выбора C vs C++
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, abdul.zycor, Вы писали: AZ>Написав код в студии я сразу же пытаюсь его отлаживать, протрейсить его весь или частично
Да ну, бросай ты это дело. Если время есть — лучше и правда тест написать — на будущее останется.
Здравствуйте, Vamp, Вы писали:
IID>>Тем не менее это не мешает "мясо" библиотеки писать на С++, а наружу выставлять pure-С API. Вон, в винде дофига юзерленда именно так сделано. V>Ну это кривизна необыкновенная. Когда два С++ класса общаются между собой на C, и лишены возможностей взимодействовать с использованием возможностей С++. И то, как это сделано в ВинАПИ, кстати, есть тоже кривулина.
Всё дело в волшебных пузы^W^W правильной декомпозиции. Зато "внутренности" православно написаны на плюсах. К тому же задействование возможностей С++ во внешних интерфейсах автоматически кладёт болт на другие языки. Т.к. биндинги к pure-С есть у всех, а с С++ это не так.
Здравствуйте, Vamp, Вы писали:
_>>Для этого extern C есть. V>Особенно он полезен, когда в библиотеку помещаются классы.
Этот аргумент невероятно полезен при сравнении С++ и С. Или при использовании С ты сможешь экспортировать классы?
Здравствуйте, abdul.zycor, Вы писали:
AZ>Всем привет! Не так давно стал изучать программирование для unix систем. AZ>Возникло впечетление, что большая часть кода всяких серверов написана на с, а не на с++. AZ>Вот возникает вопрос почему так, когда с++ современее, удобнее. Есть библиотеки типа boost, stl. AZ>Какие могут быть обьяснения тому? AZ>У меня такие: AZ>Почему пишут на с: AZ>1. в отладчике gdb приятнее видеть короткий простой код на с AZ>2. не знают с++, поэтому пишут на с AZ>3. переносимость под другие платформы, все же мне кажется код на с переносимее чем на с++ AZ>4. нет инструментов типа, таких как под винду, для рефакторинга и прочее, с инструментами типа gdb, emacs, vim п омоеум сложнее писать на с++ AZ>5. мног окода написано уже на с, хоят и новые почему-то пишут на с
AZ>В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста.
C++ позволяет сильно автоматизировать и упрощать многие вещи (та же работа со строками или STL). Это не означает, что на C++ нельзя написать код, идентичный по производительности коду на C и при этом занимающий в 2 раза меньше строк. Но означает, что для того, чтобы написать громоздкое приложение на C надо писать много кода, на C++ для этого достаточно пару раз не задуматься о последствиях и поюзать стандартные конструкции кривым способом.
Например, хэш-таблицу для повторяющихся строк на C можно реализовать, вручную распихав строки в едином блоке без дублирования совпадающих подстрок и сделав вычисление хэшей. Займет это N строк. На C++ все можно реализовать аналогично низкоуровнево, займет это меньше N строк и будет иметь красивую модульную структуру. НО всегда найдется программист, который поюзает std::map<std::string, std::string>, не вьезжая в принцип его работы, чем увеличит требуемый размер памяти в разы.
На практике получается, что объяснить программистам, как писать компактный и производительный код на С++ сложнее, чем запретить им пользоваться чем-либо кроме C. Увы.
Примерно как с автопилотом. Если в течение всего полета следить за курсом, картой, маяками и поддерживать направление вручную, полет пройдет по плану. Если задать в автопилоте план полета с координатами, полет также пройдет нормально. Но если пустить к управлению немотивированного "быдлокодера", он выставит на автопилоте примерный курс и уйдет спать, в результате чего ошибка в 1 градус при указании курса выльется в стокилометровый уход от цели.
Здравствуйте, bazis1, Вы писали:
B>Примерно как с автопилотом. Если в течение всего полета следить за курсом, картой, маяками и поддерживать направление вручную, полет пройдет по плану. Если задать в автопилоте план полета с координатами, полет также пройдет нормально. Но если пустить к управлению немотивированного "быдлокодера", он выставит на автопилоте примерный курс и уйдет спать, в результате чего ошибка в 1 градус при указании курса выльется в стокилометровый уход от цели.
Думаю в тут можно заменить "быдлокодера" на "быдлолетчика" ))
Здравствуйте, Ikemefula, Вы писали:
PD>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.
I>Это как бы ЯВУ, на самом дело недо-ЯВУ.
Совместимость с C делает его недо-ЯВУ.
Если из него убрать все эти недо-ЯВУ, то будет Java или C#.
Одна из таких попыток — это Managed C++ Микрософта.
Здравствуйте, труженик села, Вы писали:
PD>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.
I>>Это как бы ЯВУ, на самом дело недо-ЯВУ.
ТС>Совместимость с C делает его недо-ЯВУ.
Objective-C тоже совместим с С, но при этом он настоящий ЯВУ.
ТС>Если из него убрать все эти недо-ЯВУ, то будет Java или C#.
Здравствуйте, abdul.zycor, Вы писали:
AZ>Написав код в студии я сразу же пытаюсь его отлаживать, протрейсить его весь или частично ну если это возможно.
Я всегда говорил, говорю и буду говорить, что программист, которому нужен отлЯдчик для только что написанного им кода — плохой, негодный программист.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>С++ — это ЯВУ, согласен. Жаль только, что уже давно появились мега-ЯВУ, гипер-ЯВУ, супер-ЯВУ и, конечно же, пупер-ЯВУ. Со всеми вытекающими...
На которых пишут не программисты (как на С++), а всякие супер- и пупер-программисты
Здравствуйте, BigBoss, Вы писали:
BB>Здравствуйте, abdul.zycor, Вы писали:
AZ>>Какие могут быть обьяснения тому?
BB>http://www.kernel.org/pub/linux/docs/lkml/#s15-3
[quote]There is no point in just compiling the kernel with g++ and writing the odd function in C++, this would just result in a confusing mix of C and C++ code. Either the kernel is left in C, or it's all moved to C++.[/quote]
Ну это просто зашибись аргумент. Типа, или всё бросить и начать сначала, или ничего не трогать и закрыть глаза на удобные фичи C++. Ну типа нах нам автоматическая коробка, ведь это надо все машины с ручной в утиль сдать, а потом выпускать на улицы автомат. А то чтобы по одной улице одни ездили на "ручке", а другие на "автомате" — это же некошерно. Да и Торвальдс не разрешит.
О том, как бы поюзать часть удобных фич C++, дабы быстрее и качественнее решить проблемы, стоящие перед разработчиками сейчас, никто и не задумывается. Элементарно можно создать inline wrapper-ы на С++ вокруг существующего API на C — вызывать будет удобнее (те же mutex guard-ы можно красиво реализовать), размер бинаря не увеличит, ибо все разрезолвится во время компиляции. Ту же VFS сделать на базе виртуальных функций, чтобы унаследовал класс, переопределил 3 метода, вернул new MyClass(); из entry point — и VFS юзабельна. Но ведь нет — куда кошернее руками заполнять таблицы указателей и кастить inode->extension к struct my_vfs_driver_extension в каждом вызове...
ну если это возможно. А написав код в виме, например трейсить его лишний раз в gdb желание отпадает, ну конечно остается только смотреть логи.
на самом деле gdb довольно хорошо умеет работать и с с++.
