Здравствуйте, Трололоша, Вы писали:

Т>Здравствуйте, мыщъх, Вы писали:

Т>make файлы вместе со студией как правило используют редко ибо они кошмарно неудобны
Т>в сравнении со студийными проектами. Можно придумать конечно пару use case когда
Т>в make будет подправить проще чем в студии, но это будут частные случаи.
шутить изволите? я не в курсе студии и мне просто интересно -- там уже появилась интеграция с системами контроля версий? ну типа задал путь для чекаута -- оно скачало файлы, включило их в проект. если нет -- зачем вообще нужна студия?! как с ней работать-то?! если IDE от слова "интеграция", то это интеграция чего и чем?

Здравствуйте, мыщъх, Вы писали:

М>шутить изволите? я не в курсе студии и мне просто интересно -- там уже появилась интеграция с системами контроля версий? ну типа задал путь для чекаута -- оно скачало файлы, включило их в проект. если нет -- зачем вообще нужна студия?! как с ней работать-то?! если IDE от слова "интеграция", то это интеграция чего и чем?

не ко мне вопрос, но ) в студии, не помню с какой версии, но довольно давно, система интеграции с системами контроля версий сделана через плагины. Соответственно существуют плаги и для svn и для git (то что использовал) — бесплатно и опенсурсно. Они довольно удобные надо сказать.

Здравствуйте, MTD, Вы писали:

MTD>Здравствуйте, мыщъх, Вы писали:

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

MTD>Это называется — бардак. У нас человек из разработчиков библиотеки даже ревьюит как она используется.

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

еще раз обращаю ваше внимание, что у всех нормальных людей есть задачи, сроки их выполнения и они отчитываются о проделанной работе. допустим, эта библиотека была написана год назад и у автора в планах поддержать фичи foo и bar в следующем квартале. а сейчас ему необходимо сдать документацию или подготовить отчет по проекту baz, от которого зависят петя и дима, а потому планируют свою работу, ореентируясь на вас. если васе нужны фичи smap и eggs, то в ваши планы не входит их реализация. более того, вам вообще не упало включать их в документацию и основной бранч. даже если вы считаете, что smap это фигня, а eggs -- полезная фича, то вы можете включить ее в основную ветку, если вася реализует ее подобающим образом. а вот бросать все и ложиться под васю -- руководство не оценит, а петя и дима могут и бонусов лишиться, т.к. из-за вас у них все пойдет кувырком...

короче, есть ПЛАН и все ему следуют. только в детских сказаках задачи выполняются независимо. в реальности зависимость очень даже сильная и потому когда на меня падает незапланированная задача это означает либо, что мне придется овертаймить, либо передавать одну из своих задач наименее загруженному члену. вы с этим согласны?

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

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

MTD>>>В большом проекте репозиториев несколько и право на изменение есть только у тех, кто данный код поддерживает.
М>>вообще-то в большом проекте право на чтение есть далеко не у всех. у меня есть право на чтение только моего кода. и совсем чуть-чуть на код коллег (в той части, в которой мой код с ними работает), но в куче веток у меня права нету, ибо не положено.
MTD>К чему тогда вопрос?
вопрос почему вы считаете ситуацию когда у разных людей разные допуски бардаком? допуск на чтение -- это тоже допуск. и этого допуска может банально не быть. если у меня нет допуска на чтения некоторой ветки и мне даже не положено знать о ее существовании, то кто и почему будет сообщать мне, что там используется мой код? считаем, что меня вообще нет. уволился или машина переехала. это что-то меняет?

М>>и я не в курсе как вообще вызывается мой код. может он вызывается неправильно или неоптимально.
MTD>Бардак, о чем я и писал выше.
скажите, вы посылаете свой код в ms? ну чтобы разработчики винды удостоверились, что вы нигде не накосячили? очень может быть, что посылаете, т.к. у ms есть куча программ по сертификации софта на соответствие качеству, но этим не разработчики занимаются, а совсем другие люди.

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

Здравствуйте, izl3sa, Вы писали:

I>к примеру интеграция msvc2010 с build из wdk посредством makefile project для компиляции драйверов много удобнее, чем правка проекта под них
Это проблема VC2010, они там зачем то vcproj так сломали что даже простой проект под 2010ю импортнуть она не всегда осиливает.
Мы 2010 и 2012 вообще решили пока пропустить, один фиг компилер у нас не МС используется.

Здравствуйте, мыщъх, Вы писали:

М>бардак это когда использование библиотеки согласовывается с автором. кто он такой?! если это библиотека, то там должна быть документация, примеры использования и все остальное. у всех, у кого есть доступ к этой части проекта, могут (и должны) использовать библиотеку без консультаций с автором. и код должен быть чистым, ясным и понятным, чтобы бранчить без помощи автора. даже если это ваш коллега, который сидит с вами рядом -- если _ему_ что-то нужно прикрутить, то он это и крутит, конечно, в своем бранче.

Это демагогия:
1. Никто не отрицает, что код должен быть понятным, должна быть документация, примеры и т.д. (кстати вы уже писали, что документация есть не всегда, ваши библиотеки используют возможно не оптимально, отчего кстати? Код запутанный, документации нет?).
2. Вести свой бранч и есть бардак. Вот придут ко мне как разработчику и покажут баг, исправлю я его, а потом еще что-то допишу и улучшу, как это в вашу ветку попадет? А могли бы мне в крайнем случае патч прислать.

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

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

М>короче, есть ПЛАН и все ему следуют. только в детских сказаках задачи выполняются независимо. в реальности зависимость очень даже сильная и потому когда на меня падает незапланированная задача это означает либо, что мне придется овертаймить, либо передавать одну из своих задач наименее загруженному члену. вы с этим согласны?

Конечно нет — это так только в детских сказках. В компаниях с налаженной коммуникацией и планированием все гибко. Более того, скажу вам страшную тайну — планы постоянно меняются.

М>простая и всем известная истина: хочешь что-то сделать -- делай это сам. просить о фиче -- это ждать неопределенное время с вероятностью получения отказа.

Когда в компании бардак — безусловно.

М>да, вася может попросить рукводителя попросить реализовать эту фичу, обосновав это тем или иным образом. а простить автора напрямую -- это и есть бардак. и отмазка в стиле "меня попросили, я думал, что работы на полчаса, а оказалось... ну короче, я сорвал все сроки по основным задачам и реализовал прихоть васи".

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

MTD>>>>В большом проекте репозиториев несколько и право на изменение есть только у тех, кто данный код поддерживает.
М>вопрос почему вы считаете ситуацию когда у разных людей разные допуски бардаком?

Не приписывайте мне свои фантазии — разделение прав это замечательно.

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

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

М>считаем, что меня вообще нет. уволился или машина переехала. это что-то меняет?

Натурально бардак

М>>>и я не в курсе как вообще вызывается мой код. может он вызывается неправильно или неоптимально.
MTD>>Бардак, о чем я и писал выше.
М>скажите, вы посылаете свой код в ms? ну чтобы разработчики винды удостоверились, что вы нигде не накосячили? очень может быть, что посылаете, т.к. у ms есть куча программ по сертификации софта на соответствие качеству, но этим не разработчики занимаются, а совсем другие люди.

До абсурда можно довести что угодно.

М>в чем разница? если вам нужно изменить стандартную библиотеку компилятора или винды, то ms теоритически может удовлетворить такой фич реквест, но, скорее всего, вам ответят отказом. ну не в ms так в опен-сурс проект.

Ага, жизнь штука непростая, так зачем еще к этому и у себя бардак разводить?

Т>Это проблема VC2010, они там зачем то vcproj так сломали что даже простой проект под 2010ю импортнуть она не всегда осиливает.
Т>Мы 2010 и 2012 вообще решили пока пропустить, один фиг компилер у нас не МС используется.

ну нет, просто использование компилятора не из wdk не рекомендуется ms + там довольно много чего настраивать нужно в проекте (хотя только один раз и использовать в качестве шаблона), хоть 2010 хоть 2003 без разницы, но мне это показалось все равно излишне гемморно + теряется возможность компилировать без установки студии, чего многие хотят. Так что makefile project видится мне лучшим решением всё же.

Здравствуйте, мыщъх, Вы писали:

Крис, посмотрите пожалуйста личку

KP>>Относительно скоро буду менять работу. Куда резюме слать?
М>шлите на английском на gleet#novabsdm^com, с пометкой, что от питона, а я перешлю руководству, что человека знаю по форуму и знаю, что он неглупый. если будете в наших краях (NOVA), то с удовольствем приглашаю на чай.

Это хорошо когда на постоянку и чумаданы собраны, а вот как фриланс хороший на С найти?

М>шутить изволите? я не в курсе студии и мне просто интересно -- там уже появилась интеграция с системами контроля версий?

Году, помнится, в 2000м, я еще из (5й? 6й? не помню) Студии делал checkout в системе контроля версий (ну и что что SourceSafe ). Не надо на студию набрасывать. В роли инструмента разработчика она — лучшее, что есть для С/С++.

Здравствуйте SkyDance, Вы писали:

SD>... Не надо на студию набрасывать. В роли инструмента разработчика она — лучшее, что есть для С/С++.

Это спорное утверждение. На Eclipse CDT можно прекрасно разрабатывать, при том интеграция лучше и кросс-платформа. На вкус и цвет...

AG>Это спорное утверждение. На Eclipse CDT можно прекрасно разрабатывать, при том интеграция лучше и кросс-платформа. На вкус и цвет...

Я сейчас с этим г...оубожеством _вынужден_ работать на работе. Так вот, Eclipse CDT просто жесть кошмарная в сравнении со студией, особенно жестко глючащая при установке брейкпоинтов и выводе всяких там watches.

Здравствуйте SkyDance, Вы писали:

AG>>Это спорное утверждение. На Eclipse CDT можно прекрасно разрабатывать, при том интеграция лучше и кросс-платформа. На вкус и цвет...

SD>Я сейчас с этим г...оубожеством _вынужден_ работать на работе. Так вот, Eclipse CDT просто жесть кошмарная в сравнении со студией, особенно жестко глючащая при установке брейкпоинтов и выводе всяких там watches.

Возможно, ты не умеешь готовить. У меня все работало как часы на убунте и макоси.

AG>Возможно, ты не умеешь готовить. У меня все работало как часы на убунте и макоси.

Безо всяких "возможно" — мы пишем очень разный софт. Любое достаточно большое (не любительские тырканья, а коммерческая разработка) приложение проще писать и отлаживать именно в Студии. Причем я не одинок в этом подходе.
И сама IDE комфортнее. Хотя бы банально интерфейс лучше продуман.
Если бы не дебаггер, я бы вообще работал в студии, собирал gcc (благо, она это умеет).

Ты меня раскусил- исключительно наколенке пишу

Здравствуйте, ArtemGorikov, Вы писали:

AG>Здравствуйте SkyDance, Вы писали:

AG>>>Это спорное утверждение. На Eclipse CDT можно прекрасно разрабатывать, при том интеграция лучше и кросс-платформа. На вкус и цвет...

AG>Возможно, ты не умеешь готовить. У меня все работало как часы на убунте и макоси.
поддерживаю. кстати, "дебаггер не нужен" (с). я _действительно_ не понимаю зачем он? отладочная печать, продуманная система логгирования, тесты. если мы говорим про "больше и серьезное", то огромный пласт ошибок связан с синхронизацией, ударами по памяти... огромное кол-во багов не удается воспроизвести, особенно если баги возникают у клиента и могут быть связаны с чем угодно.

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

дебаггер решает узкий класс задач. а логгер практически не имеет ограничений.

Здравствуйте, мыщъх, Вы писали:

М>поддерживаю. кстати, "дебаггер не нужен" (с). я _действительно_ не понимаю зачем он? отладочная печать, продуманная система логгирования, тесты. если мы говорим про "больше и серьезное", то огромный пласт ошибок связан с синхронизацией, ударами по памяти... огромное кол-во багов не удается воспроизвести, особенно если баги возникают у клиента и могут быть связаны с чем угодно.

Согласен. Правда мне за такое мнение здесь как-то минусов от души поставили

Здравствуйте, мыщъх, Вы писали:

AG>>Возможно, ты не умеешь готовить. У меня все работало как часы на убунте и макоси.
М>поддерживаю. кстати, "дебаггер не нужен" (с). я _действительно_ не понимаю зачем он?
Это потому, что ты видимо так и не научился им пользоваться.
Это два сильно разных подхода. Логи и отладочный вывод хорош для отлова определённого круга багов, отладчик — для другого.
Там где хорош отладчик — никакая отладочная печать не поможет. Ибо её придётся воткнуть буквально после каждого выражения, причём каждый раз выводить огромное колво переменных, а то и областей памяти.
Ну и там где хороши логи — там отладчик слабо помогает.
Ну а пользоваться надо уметь всем спектром инструментария — сильно упрощает жизнь.

М>наконец, отлаживать в дебаггере реально только дебажную версию. генерация символьной инфы для релиза сильно затруднена, особенно если это глобальная оптимизация с активным инлайном функций.
Ну ассемблер то отлаживать можно. Встроить бы функционал от IDA по навигации по асму в вижуалку, ну или вижуаловский отладчик в IDA — вышел бы мегатул.

М>а логгер практически не имеет ограничений.
Имеет. Логи на каждый чих писать просто физически не получится.

Здравствуйте, Трололоша, Вы писали:

Т>Здравствуйте, мыщъх, Вы писали:

AG>>>Возможно, ты не умеешь готовить. У меня все работало как часы на убунте и макоси.
М>>поддерживаю. кстати, "дебаггер не нужен" (с). я _действительно_ не понимаю зачем он?
Т>Это потому, что ты видимо так и не научился им пользоваться.
бинарные файлы отлаживаю всем чем угодно. от удаленной отладки через интерактивную иду, до PyDbg, который есть "собери себе отладчик из лого". кстати, в силу этого у меня стиль отладки довольно специфичный.

if (__DEBUG__) if (break_point_Nxx_enabled) if (условие) __asm{int 0x3}.

уже объяснял преимущество такого подхода. мне условия легче писать в большом окне редактора, а не в маленьком окне псевдоредактора бряков. второе -- мои бряки сохраняются в исходном файле и не зависят от IDE. от платформы они тоже не зависят, если __asm{int 0x3} это макрос. причем, они могут включаться не только путем перекомпиляции, но и правкой конфига.

Т> Логи и отладочный вывод хорош для отлова определённого круга багов, отладчик — для другого.
логи покрывают все баги отладчика, а отладчик покрывает возможности лога только частично

Т> Там где хорош отладчик — никакая отладочная печать не поможет.
Т> Ибо её придётся воткнуть буквально после каждого выражения,
Т> причём каждый раз выводить огромное колво переменных, а то и областей памяти.
все именно так. только это легко автоматизировать. даже самый примитивный логгер может распарсить исходный текст и автоматом воткнуть логгинг при вызове каждой функции и на выходе из нее. нормальные функции это десяток строк и обычного достаточно логгировать их вызов и аргументы. но так же можно воткнуть логгер после каждого выражения.

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

Т>Ну а пользоваться надо уметь всем спектром инструментария — сильно упрощает жизнь.
конечно, когда приходится исследовать программу, взаимодействующую с чужими модулями, то это сильно облегчает жизнь.

М>>а логгер практически не имеет ограничений.
Т>Имеет. Логи на каждый чих писать просто физически не получится.
да ладно вам. вместо того чтобы давать на Step-in/Step-Over достаточно записать трассу в лог (это даже олька может) и визуализовать ее -- намного быстрее ошибки находятся, особенно если сравнивать поломанную трассу с той, что еще вчера работала. разумеется, сравнение идет на уровне блоков control flow. автоматически подсвечиваются различия. и там мы уже смотрим на значение переменных (регистров) и думает почему оно так.

_интерактивный_ отладчик полезен только для маленьких проектов, состоящих из одного файла (исполняемого). как только у нас появляется хотя бы база данных... ну и потом, если мы говорим не за кружок умелые руки, то промышленное программирование это RESTful, XML-RPC и куча других умных слов. даже если вы пишите калькулятор, задумайтесь -- его же по хорошему неплохо бы включить в Google Apps и вообще сделать web-версию, т.к. "обвязку" написать несложно. во всяком намного проще, чем парсить математические выражения и решать системы уравнений. ядро явно писать на си или плюсах. или на ди. или на хаскеле. но ни один из них не подходит для веба. и там будет или шарп или руби. или жаба. кстати, на вашей девелоперской машине вообще может не быть ни базы данных, ни веб-сервера. вы компилируете си в библиотеку, вызываемую из того же пиона, и делаете SSH на никсовый сервер. вопрос -- как вы будете это отлаживать? интерактивным отладчиком? или все-таки забьете на отладчик и возьмете в руки логгер.

усложним ситуацию. вы разрабатываете модуль для системы, к которой у вас нет доступа, а только спецификация взаимодействия. на вашей локальной машине ваш модуль на си работает и проходит все тесты, а вот в составе системы -- не пашет. отладчик говорите? а это и есть серьезное промышленное программирование. ну даже если вам дадут доступ по SSH. ну зайдете вы туда. а там такой бармалей. куча очередей, куча потоков и куча экземляров вашего модуля выполняется сразу. а если модуль задумается хотя бы на 15 сек -- поток прибивают лопатой. за этим следит отдельный сторож. так что даже подрубившись к своему модулю по gdb вы должны отлаживает его с реактивной скоростью, ибо увеличивать тайм-ауты вам не дадут. т.к. если мы задумаемся на 150 сек, то уже прибивается весь процесс и делает total reset с откатом.

М>"дебаггер не нужен" (с). я _действительно_ не понимаю зачем он?

Научишься пользоваться, узнаешь.
Может, даже постигнешь высокое искусство дебажить (в основном в disasm) программы с -O3 и другими оптимизациями.

М>дебаггер решает узкий класс задач. а логгер практически не имеет ограничений.

У логгера есть только одна проблема — ту, что еще тов. Гейзенберг описал. Гугли принцип неопределенности: включая логирование, ты воздействуешь на процесс исполнения. Никогда не сталкивался с вариантом, когда с логами все работает, без — нет?

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

Порой ты вроде разумно пишешь. Но иногда как ляпнешь, так удивляться приходится.
Мне логгер еще ни разу не позволил вернуть IP (который регистр, а не адрес) назад и _с текущими переменными_ еще раз выполнить по шагам вот эту функцию. Про принцип неопределенности я уже писал — включенное логирование изменяет поведение программы.

Короче говоря. Это два разных инструмента. Логи, это как посмертное вскрытие — можно констатировать, что пациент 16.09.2011 заболел триппером, вылечился 25.09.2011, а 14.03.2012 упал в канализационный люк и умер. Дебаггер и crash dump (при умелом использовании) тебе покажет видеосъемку, как пациент шел по улице, смотрел на грудь проходившей мимо женщины, не увидел открытый люк, и упал в него. Потом умер.