среда разработки

Десктопные приложения на си вроде как не пишут. Без обьектной модели далеко не уедешь.

офигеть. каждый день что-то новое придумывают.

Если у тебя есть фонтан, заткни его; дай отдохнуть и фонтану.

это ты про себя?

А разве MSVS C поддерживает?

поддерживает c89. но можно прикрутить другой компилятор. но тогда оно перестает быть ide, т.к. дебагер тоже приходится использовать другой :)

Но как же «не получается», если
1. я установил вим
2. автокомплит НЕ работает

Вполне себе получается.

один мой товарищ показывал автокомплит в виме для питона. Обошлось ему это где-то в полдня возни.

Вполне себе получается.

а у меня вот что-то никак не получается. давай на яблоках попробуем. у пети больше яблок чем у васи, но у пети яблоки зеленые и красные, а у васи есть еще и желтые. у кого больше яблок?

Обошлось ему это где-то в полдня возни

Да, совсем ничего. Жизнь - она же резиновая.

Насколько мне известно голый си используется только в ядре и при программировании embedded фиговин.

apache, nginx, git, SVN, gtk - это только то, что мне сразу приходит в голову.

Десктопные приложения на си вроде как не пишут

Gnome.

Вы так говорите как будто на виме свет клином сошелся, если вы не осилятор/у вас что-то не работае в виме, то это не значит что так оно на самом деле и что нет других ide/редакторов для GNU/Linux.

Думаю товарищъ waker еще как подтвердит, что десктопные приложения на C пишут ;)

такс что поставить то? Все спорят, и все советуют разное

Пробуй разное, что понравится, то и используй.

apache, nginx, git, SVN, gtk - это только то, что мне сразу приходит в голову.
Gnome.

спасибо большое, буду знать. Ошибался

Центральную роль в GNOME играет инструментарий GTK+, который предоставляет средства для создания графических интерфейсов. В состав GTK+ также входят вспомогательные библиотеки:
...
GObject — объектно-ориентированный каркас для программирования на Си;
Объектная система GLib или GObject — библиотека с открытым исходным кодом (лицензируется под LGPL), представляющая портируемую объектную систему и прозрачную межъязыковую совместимость.

а зачем они все так усложнили?

Никто же не спорит об этом. Но разговор (если это можно так назвать) идет об «изкаробочности». А то что автокомплит вим не умеет «изкаропки» - это факт...

Оба варианта говно полное. А говорить о серьезной работе с такими инструментами и вовсе не стоит.

Господин тролль, прошу правильный инструмент в студию.

У них Си++-фобия.

Какой петя, какие яблоки?? Вполне реальный софт и вполне реальная фича и вполне реальная ситуация.

Функция автодополнения не присутствует в установочных пакетах во всех известных мне дистрибутавах, равно как и в сорцах. Т.о. посля установки эта функция отсутствует, а это значит что это «фичи» нет «изкаропки».

Или по твоему отсутсвие этой функции означает что она присутствует?

А то что автокомплит вим не умеет «изкаропки» - это факт...

:h new-omni-completion

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

но через плагины должен уметь вполне нормально. могу проверить, когда дома буду, если есть интерес.

Или по твоему отсутсвие этой функции означает что она присутствует?

перечитай еще раз что ты пытался доказывать, и что ты пытаешься доказывать сейчас. а то у меня возникло ощущение, что ты в собственных сообщениях запутался.

а зачем они все так усложнили?

затем, что им нужна стабильная обратная совместимость API и ABI, чего средствами C++ сделать нельзя.

с плагинами все пучком :)
А вот С++ изкаропки не умеет, ну хоть ты тресни )

p.s. это конечно если не считать того, что gobject превосходит по фичам объектную модель C++, поддерживая introspection и многие динамические фичи, которые голому C++ и не снились, и решаются только гигантскими костылями.

им нужна стабильная обратная совместимость API и ABI, чего средствами C++ сделать нельзя.

Бугага.

А вот С++ изкаропки не умеет, ну хоть ты тресни )

так у меня даже в мыслях не было доказывать, что в vim есть нормальный автокомплит для C++ искоробочно.

что смешного?

что смешного?

Изложение штампов без всякой попытки мыслить.

стабильная обратная совместимость API

Сделано Qt

и ABI,

Стандарт ABI давно есть

чего средствами C++ сделать нельзя.

False

gobject превосходит по фичам объектную модель C++, поддерживая introspection и многие динамические фичи, которые голому C++ и не снились

Помимо передергивания насчет «превосходит» и «не снились», есть еще одна вещь: gobject и intorspection появились гораздо позже Gnome. Т.е. разрабы Gnome натыкались на убогость Си и по ходу дела изобретали костыли.

Eclipse, нормальная тема )

А мы как бы об этом :)
Про плугины я в курсе, т.к. сам использую.

Сделано Qt

пруф?

Стандарт ABI давно есть

на протяжении последних ~6 лет ломался 2 или 3 раза, на моей памяти. видимо, он недостаточно давно есть.

gobject и intorspection появились гораздо позже Gnome

это к чему вообще?

Сделано Qt

пруф?

Попробуй писать на Qt

Стандарт ABI давно есть

на протяжении последних ~6 лет ломался 2 или 3 раза

Пруф?

gobject и intorspection появились гораздо позже Gnome

это к чему вообще?

Там написано.

некорректное сравнение. vim имеет больше фич для написания кода, чем kdevelop и qtcreator вместе.

KDevelop конечно довольно сырой, в QtCreator тоже хватает недостатков, но и голый vim - всего лишь удобный текстовый редактор. Без вменяемого С++ индексера невозможны например такие вещи:

• навигация по коду
  
• семантическое автодополнение (а не тупое дополнение (ctags) из кучи уже имеющихся в коде идентификаторов/слов)
  
• автоматическое сворачивание неактивных блоков кода (директивы препроцессора)
• outline
  
• иерархия классов
  
• иерархия вызовов
  
• поиск ссылок на идентифкатор
  
• переименование идентификатора по всему проекту
  
• определение функции по существующему объявлению
  
• семантическая подсветка кода
  Кроме того что-то я сомневаюсь, что в vim из коробки есть средства для взаимодействия с системами контроля версий, просмотра и слияния diff'ов и т.п. Ты конечно можешь сказать что ничем из вышеперечисленного не пользуешься, но тогда ты либо гениальный человек, либо не работал в команде над большим проектом с массой чужого кода, где подобные подсказки порой очень облегчают жизнь.

Попробуй писать на Qt

все так сложно? можно проще проверить, попробовав запустить бинарник qt-приложения старой версии на свежем qt, или попытавшись его собрать со свежим qt sdk. как думаешь, стоит пытаться?

на протяжении последних ~6 лет ломался 2 или 3 раза

Пруф?

C++ ABI в gcc ломали в 3.1, 3.2, 3.4 и до этого при переходе с 2.95 на 3.0.

в msvc ломали раньше в каждом мажорном релизе, потом _кажется_ перестали ломать в релизах 2003-2008, в 2010 снова сломали.

думаю, нагуглить подтверждение не составит большого труда. это популярная тема :)

Там написано.

я вижу, что там написано. я не понимаю к чему это, и что оно доказывает. ну написали чуваки gobject, и сделали на основе его gnome и gtk (2 и 3). это чем-то плохо? думаешь, если бы перешли на C++, было бы лучше?

C++ ABI в gcc ломали в 3.1, 3.2, 3.4 и до этого при переходе с 2.95 на 3.0.

ну вы ж сами понимаете, что это уже не проблема

в msvc

там библиотеки на С++ приходится таскать с собой, за неимением репозитория с оными, так что это и не было проблемой

невозможны например такие вещи

для С хватает ctags, для C++ вполне хватает cscope (для второго нужен дополнительный плагин, первое искоробки)

семантическое автодополнение (а не тупое дополнение (ctags) из кучи уже имеющихся в коде идентификаторов/слов)

для C++ вроде выяснили что решается плагином

автоматическое сворачивание неактивных блоков кода (директивы препроцессора)

в виме есть фолдинг. есть и ручное, и автоматическое сворачивание по заданным правилам, и по меткам в коде.

outline

если под этим словом подразумевается то что в меню Outline в msvs — то вим это умеет.

иерархия классов

ctags + скрипт

иерархия вызовов

не уверен что это

поиск ссылок на идентифкатор

cscope

переименование идентификатора по всему проекту

примитивное что-то есть. но если есть нужда в рефакторинге — лучше юзать адекватные тулзы для этого. в принципе, если очень хочется, есть eclim.

определение функции по существующему объявлению

ctags/cscope

семантическая подсветка кода

не уверен что это.

Кроме того что-то я сомневаюсь, что в vim из коробки есть средства для взаимодействия с системами контроля версий

для нескольких опенсорсных есть, для проприетарных добавляется элементарно через vimrc (использую совместно с perforce)

просмотра и слияния diff

vimdiff

Ты конечно можешь сказать что ничем из вышеперечисленного не пользуешься

пользуюсь же, хотя и не всем этим :)

либо не работал в команде над большим проектом с массой чужого кода, где подобные подсказки порой очень облегчают жизнь

я выше писал, что для больших проектов использую msvs, как и вся остальная команда. cscope не справляется с проектами на 300K исходных файлов (как и голые вижуалы — только через VAX). подозреваю, что kdevelop и qtcreator тоже умерли бы.

ну вы ж сами понимаете, что это уже не проблема

это проблема, и ее нет в C :) в C есть проблема только с ABI glibc. но она решаема, т.к. в glibc есть multiabi.

там библиотеки на С++ приходится таскать с собой, за неимением репозитория с оными, так что это и не было проблемой

это не проблема в опенсорсе. в проприетарном софте многие библиотеки покупаются за бабло, и они работают только с той версией вижуалов в которой собраны.

особенно зачетно, когда для сборки плагина под 3dsmax нужно vc2008, но в плагине используются либы, которые уже собраны под vc2010.

CTRL+F сказал мне, что в этой теме еще не упоминали gedit+gcc

в C есть проблема только с ABI glibc. но она решаема, т.к. в glibc есть multiabi.

ps: в винде эта же проблема решается через SxS assemblies.

в C есть проблема только с ABI glibc. но она решаема, т.к. в glibc есть multiabi.

если говорить про glibc то там есть просто огромная проблема с совместимостью сверху-вниз, в венде можно собрать программу на восьмерке и запустить в 98-й, в линуксе так не получится даже с предыдущей версией, или есть таки вариант, кроме как вручную собрать glibc или хаков для каждой функции отдельно?

в венде можно собрать программу на восьмерке и запустить в 98-й

тут дело не в том, под какой вендой собирать, а какими версиями вижуалов. я точно не уверен, но краем уха слышал, что свежие вижуалы уже не поддерживают win9x.

в линуксе так не получится даже с предыдущей версией, или есть таки вариант, кроме как вручную собрать glibc или хаков для каждой функции отдельно?

при сборке нужно указать линкеру какую версию ABI glibc использовать. также нужно вычистить косвенные зависимости, иначе бинарник слинкованный с gtk будет просить (например) libpng14, т.к. гтк в сборочной системе его требует. я так собираю deadbeef — собираю на системе с последними glibc/gcc, запускается на glibc2.7 и выше. сделать это все вручную трудно, и я многих деталей не знаю/ не понимаю, за меня об этом заботится скрипт apgcc из (ныне мертвого) autopackage. сейчас это хозяйство живет в listaller.

при сборке нужно указать линкеру какую версию ABI glibc использовать

можно плз ткнуть носом в документацию

От и круто же вы все помогли ТСу.

ТС, с чем раньше работали-то?

можно плз ткнуть носом в документацию

никакой документации про это сходу нагуглить не смог. надо смотреть в исходники apgcc, и разбираться какими параметрами это делается.

Я бы рекомендовал emacs.

никакой документации про это сходу нагуглить не смог. надо смотреть в исходники apgcc, и разбираться какими параметрами это делается.

посмотрел, ничего нового там нет, способ аналогичный описанному тут:

http://www.trevorpounds.com/blog/?p=103

только автоматизированный, жаль, хотя в принципе сборка в chroot особых проблем не доставляет, но хотелось бы прямого решения

это вроде и есть самое прямое решение, которое бывает :)

это вроде и есть самое прямое решение, которое бывает :)

сборка с glibc нужной версии таки прямее и верней

можно проще проверить, попробовав запустить бинарник qt-приложения старой версии на свежем qt, или попытавшись его собрать со свежим qt sdk. как думаешь, стоит пытаться?

Стоит. Потом то же самое сделать с GNOME-приложением, сравнить результаты.

C++ ABI в gcc ломали в 3.1, 3.2, 3.4

Так пруф будет или нет? Исходя из:

waker> на протяжении последних ~6 лет ломался 2 или 3 раза

и того, что gcc 3.4 (последний из упомянутых тобой) вышел 8 лет назад, пруфа не будет.

и до этого при переходе с 2.95 на 3.0.

При переходе с 2.95 на 3.0 столько всего сломалось, что Си++ ABI просто никто не заметил бы. И вышел 3.0 11 лет назад.

в msvc

Nobody cares.

ну написали чуваки gobject, и сделали на основе его gnome и gtk (2 и 3). это чем-то плохо?

Костылизм, велосипедизм, NIH-синдром.

думаешь, если бы перешли на C++, было бы лучше?

Да.

Действительно, зачем идти за молотком, если можно забивать гвозди руками.