Re[11]: Берут ли в Senior Linux C++ Developers тех - О работе

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

WH>В мелкомяхких приложениях вобще и в студии тем болие вобще нет действий которые можно сделать только мышой (по крайней мере мне о таких не извесно).
Это очень смелое утверждение.
L>>Я, кстати, даже не заикнулся про повтор последней команды. В vim жмешь "." и получаешь повтор последней команды редактирования, как то регексп, копирование/удаление/вставка. Это очень сильная вещь, между прочим (не надо сравнивать с записью макросов, плиз).
WH>Как по мне совершенно безполезная. В отличии от записи макросов.
Подобное безапелляционное заявление программиста совершенно не украшает.
WH>Ибо повторить комманду я могу и шорткатом.
Любую команду?
WH>А когда нужно повторить несколько комманд... например нужно сделать switch/case по значениям некоторого enum'а.
Вы просто не представляете себе эффективную работу с текстом, чем, собственно, и являются исходники программы.
Не надо оправдываться, то, что Вы тут написали, наглядно показывает Вашу зашоренность. Вы даже представить себе не можете, что черный экран без мыши и, (о ужас!) без выскакивающих по делу и без дела окошек типа "продолжить да/нет" может быть на порядок удобнее того "эргономичного" поделия, которое Вы слепо считаете эталоном.
Тут правильно сказали — в vim/emacs заключен опыт нескольких поколений программистов, которые делали редактор, удобный в первую очередь для программистов. Студийный редактор — это блокнот, к которому привинтили подсветку синтаксиса и навесили сверху автодополнения, как бы Вы его не называли.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Совершенно не согласен. У почти каждого есть свой любимый редактор, включая, например, американских DDK MVPs — вряд ли они слабые разработчики.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

M>Поэкспериментировав с KDevelop, Eclipce и gdb пришёл к выводу, что легче под виндой кроссплатформенно проги писать и отлаживать, а на Unix один make запускать.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

L>>Вообще, господа хорошие, хочу снова напомнить анекдот про устриц. Судя по вашим возгласам, Вим/Емакс Вы видели только со стороны.
WH>Вообще, господа хорошие, хочу снова напомнить анекдот про устриц. Судя по вашим возгласам, Студию Вы видели только со стороны.
(Зевает)
Нет, ну право, весьма полезный флейм. Вот я про "Ctrl-[" узнал (справка от МС — гадость редкостная) и попутно таки нашел список дефолтных шорткатов в студии. Только вот у меня пальцы в большинстве случаев так не растопыриваюццо, да и как. к примеру, удалить весь текст с текущей позиции до конца строки (файла) или скопировать 5-6 (100-200) строк текста одним махом, не нашел

Вот обратите внимание — я одинаково успешно работаю как в одной, так и в другой системе. Я высказал список того, чего мне не хватает в студии и узнал, где регекспы и как искать парные символы. Правда, для меня редактор студии от этого сильно удобнее не стал по ряду причин, которые апологетам студии, до сих пор считающих, что vi/emacs — это такой Блокнот не от МС, понять будет сложно. Это как научиться пользоваться современным универсальным деревообрабатывающим станком, а потом опять вернуться за верстак с рубанком и ножовкой. Не надо сарказма, редактору студии в данном ряду я отвожу место топора, к которому хоть и приделали множество ручек и даже пылесос для удаления мелких щепок, удобнее не стал.

Зато вот от апологетов студии, что интересно, слышно только "где интеграция с отладчиком", и "как задолбал ваш юникс-way", ни один не спросил ничего конкретного.

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

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

C>Здравствуйте, kaa.python, Вы писали:

V>>>Хинт: не все, что тебе придеться писать можно покрыть юнит-тестами.
KP>>можно поподробнее? покрыть Юнит-тестами, либо какой-то их вырожденной формой можно все.
C>Драйверы (и ядерный код вообще), сложный код взаимодействия разных систем, код для встроеных систем. Ну и банальный GUI.
Довольно значимую часть драйвера можно покрыть юнит-тестами, кстати.
С гуем будут сложности, да. Но это лишь еще один довод в пользу разделения юзер интерфейса и логики.
C>Часто стоимость test harness будет превышать стоимость всего проекта в разы.
, елси Вы не умеете их готовить.
Правильный подход к юнит-тестированию понижает стоимость дальшейшей поддержки на порядки и даже сокращает время разработки. Если же их пишут по принципу "некогда фигней заниматься, кодить надо, нате получите и отвяжитесь", то лучше уж без них.

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

KP>>Честно сказать, человек, который без VS как без рук, у меня и на Win32 вызвал бы опасение в роли Senior Developer.

A>ты что, а как код без подсказки писать? в VS же автокомплит есть. а Сениоры не обязаны помнить синтаксис

По сравнению с ViM в студии ничего и близко напоминающего редактор кода нет, не говоря уже об автокомплитах

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

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

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

Настоящие перцы в блокноте (или аналоге) код пишут.

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

Q>И что, специально для таких editor-challenged господ покупать лицензии на ВС и Винду?

Ли-цен-зии.

+visual assist забыл, который и метод подставит, и alt+g отработает, и раскрасит по пацански
а вообще vs это наркотик, а наркотики вроде как вредны.

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

M>Здравствуйте, kaa.python, Вы писали:

M>>>Поэкспериментировав с KDevelop, Eclipce и gdb пришёл к выводу, что легче под виндой кроссплатформенно проги писать и отлаживать, а на Unix один make запускать.

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

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

До ViM редактору студии как до Парижа ползком из Усть-Мухосранска.

Ну а про отладку — не пробовали писать юнит-тесты? Я вообще отладчиком практически не пользуюсь.

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

AZ>Профессионалы пишут код при помощи головы. Пацаны типа machine3000 — при помощи Visual Studio.
Если Visual Studio позволяет писать код только при помощи конечностей и без участия головы — то M$ создало просто гениальную супер-софтину.

AZ>Без автокомплита жить можно, и даже без подсветки синтаксиса, а вот без головы совсем хреново, приходится рассчитывать на помощь IDE
Т.е. те кто пользуются IDE это люди у которых "совсем хреново"(с) с головой?

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

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

NBN>>>Чтобы было ясно — я не утверждаю, что если ты программируешь под линукс — то всёравно должен сидеть в вижуалке

Это извращение

NBN>>>Я веду к тому, что вижалка видимо один из самых удобных интсрументов для разработки, и что пренебрегать удобными инструментами не стоит

Выбор инструмента естественно по обстоятельствам.
L>>Да на здоровье. Вот только существуют инструменты и поудобнее студии, однако.

NBN>Если можно приведи примеры. С условиями: для виндов, для плюсов, инструмент лучший Студии + VA.

Речь изначально про linux шла, между прочим.

Впрочем, если гуй рисовать надобности нет, то тот же vim+make как минимум не хуже.

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

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

L>>Нет, ну право, весьма полезный флейм. Вот я про "Ctrl-[" узнал (справка от МС — гадость редкостная) и попутно таки нашел список дефолтных шорткатов в студии. Только вот у меня пальцы в большинстве случаев так не растопыриваюццо,
WH>Плохому танцору...
Вы пальцы от других частей тела отличить не можете?
L>>удалить весь текст с текущей позиции до конца строки
WH>shift + end, del
(vim)D
L>>(файла)
WH>ctrl + shift + end, del
(vim)dG
L>>или скопировать 5-6 (100-200) строк текста одним махом, не нашел

WH>home, home, shift + стрелочки или pg up/pg down и выделяешь сколько нужно.
считая в уме? Эргономично, ничего не скажешь.
(vim)100yy — скопировать 100 строк

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

WH>В студии ты работать не умеешь. Это давно понятно.
Правда, что ли? А Вы без студии вообще как без рук, похоже.
L>>Я высказал список того, чего мне не хватает в студии и узнал, где регекспы и как искать парные символы.
WH>Лично мне ни то ни другое никогда небыло нужно.
Может, пора признаться себе, что Вы просто гуевый мышевозила?

L>>Правда, для меня редактор студии от этого сильно удобнее не стал по ряду причин, которые апологетам студии, до сих пор считающих, что vi/emacs — это такой Блокнот не от МС, понять будет сложно.
WH>Может все же объяснишь?
Очень трудно объяснить это человеку, который к аргументам глух как стенка.

WH>А то ты так ничего и не назвал. Все что назвал есть в студии.
Приведенные выше шорткаты. Они есть, только использовать их банально неудобно.

WH>Все что ты продемонстрировал это не знание того как работать в студии.
Заметь, это незнание того, как эффективно работать с редактором студии. Я это и не отрицаю хотя бы потому, что он нихрена не эргоноичный.

L>>Ау, неужели не интересно, как люди без этой интеграции живут, умудряясь создавать стабильные и надежные системы?
WH>Пальци...
Пальцы это "дайте мне студию, и неважно что пишем под [unix|VxWorks|symbian...], бо без интеграции с отладчиком и жизнь не мила".

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

AZ>>Почти все упомянутое — стимулирование плохого стиля программирования.
NBN>Спорно. Сбрасывая некоторые организационные моменты на среду — ты освобождаешь время в том числе и на улучшение стиля программирования. Хотя по сути — как показывает опыт — стиль зависит ИСКЛЮЧИТЕЛЬНО от культуры программиста.

Я думаю такое мнение (что хорошее IDE плохо влияет на код) происходит оттого, что в хорошей оболочке проще работать, в итоге те люди, которым сложно или скучно осваивать командную строку, используют различные графические навороты. Естественно их код красотой не блещет. В итоге среди тех, кто использует различные графические оболочки большой процент плохих программистов.
Аналогично с бейсиком — язык слишком простой, не создаёт барьера использования. Как результат код пишут часто неопытные программисты.

C>> код для встроеных систем.
KP>тоже никаких проблем. логика с легкостью делается кросс-платформенной и тестируется на Win или Linux.

Кто бы меня научил писАть кросплатформенный код для Symbian... Расцеловал бы...

... << RSDN@Home 1.2.0 alpha rev. 676>>

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

L>Может, для начала следует научиться писать код так, чтобы не было необходимости в отладчике?
Пальцан...
Со стронней либой которая валит приложение в кору тоже без отладчика разбираться будешь?

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

C>Драйверы (и ядерный код вообще)

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

C> сложный код взаимодействия разных систем

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

C> код для встроеных систем.

тоже никаких проблем. логика с легкостью делается кросс-платформенной и тестируется на Win или Linux.

C> Ну и банальный GUI.

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

C>Часто стоимость test harness будет превышать стоимость всего проекта в разы.

часто стоимость проекта написанного по принципу "надо копать и как можно скорее" в разы превышает стоимость проектов в которых есть нормальное покрытие кода тестами.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

_M_>а отлаживают в уме

Настоящие перцы, пишут на С, в блокноте, отлаживаются в уме, ошибок не совершают и не существуют

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

A>>>1)профессионалу все равно в чем писать код. хоть в ноутпаде.
AJD>>Обоснуй, пожалуйста.

A>время на освоение очередного инструмента это мизер в общей структуре временных затрат.
A>я недавно с ClearCase разобрался за день, хотя до этого ее в глаза не видел.

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

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

NBN>>Хеловорлд легко в блокноте написать, а если нужно что-то большое и системное — то без вижалки, как без рук.
L>

L>Вот недавно сдали большой и системный комплекс контроля автомобильным трафиком. Без вижуалки. Да еще и под linux.
L>Мы что-то сделали не так?

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

Это извращение

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

Выбор инструмента естественно по обстоятельствам.

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

L>До ViM редактору студии как до Парижа ползком из Усть-Мухосранска.
Ты когда последний раз студию с поставленным Visual Assist-ом наблюдал?

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

AJD>Здравствуйте, kaa.python, Вы писали:

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

AJD>Настоящие перцы в блокноте (или аналоге) код пишут.
То-то они обычно маринованные какие-то

NBN>Настоящие перцы, пишут на С, в блокноте, отлаживаются в уме, ошибок не совершают и не существуют

"настоящий программист не всегда знает язык на котором он программирует"(с)классика

0>Здравствуйте, machine3000, Вы писали:
Кстати по этой причине и рассматриваю вариант юниксового разработчика в последнюю очередь, ибо гемор=\...хотяяя...за приличные деньги можно и стерпеть=)

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

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

L>>1.Регулярные выражения.

NBN>Расшифруй. Я достаточно часто использую рег. выражения в студии для поиска и замены.

Хм.. в самом деле, есть. Через одно место, кончено, как всегда, но вроде работает.

Зато точно нет автодополнения имени файла на диске...

AZ>>Профессионалы пишут код при помощи головы. Пацаны типа machine3000 — при помощи Visual Studio.
AJD>Если Visual Studio позволяет писать код только при помощи конечностей и без участия головы — то M$ создало просто гениальную супер-софтину.

Сколько win32 программеров могут объяснить процесс линковки? Один знакомый мне знакомый впал в глубокий ступор, когда проект отказался линковать либы с приложеним — простейщий вопрос типа unresolved symbol или неправильный тип библиотеки — и все... приплыли

AZ>>Без автокомплита жить можно, и даже без подсветки синтаксиса, а вот без головы совсем хреново, приходится рассчитывать на помощь IDE
AJD>Т.е. те кто пользуются IDE это люди у которых "совсем хреново"(с) с головой?

Нет. Совсем хреново с головой у того, кто не может собрать проект без IDE

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

З.Ы. Даже землю когда лепили и то патчи в виде диких зверей выпускали...

Posted via RSDN NNTP Server 2.0

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

V>Хинт: не все, что тебе придеться писать можно покрыть юнит-тестами.

можно поподробнее? покрыть Юнит-тестами, либо какой-то их вырожденной формой можно все.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

R>Можно рассчитывать только на 1 вещь
R>-при полностью корректных данных на входе, скорее всего все работает
Эээ..
R>на что рассчитывать нельзя
R>-для многопоточных приложений никаких гарантий нет
Почему?
R>-при корректных но не предусмотреных тестами данных никаких гарантий нет и анализ покрытия н юниттесты не скажут вам об этом если нет кода по обработке специфическог юзкейса
Это вопрос о программировании юнит-теста и стабильности алгоритма. Иногда есть смысл проверить на всем диапазоне значений, иногда это невозможно.
R>-при некорректных данных на входе никаких гарантий нет — и анализ покрытия н юниттесты не скажут вам об этом если нет кода по анализу данных
А кто запрещает написать юнит тест, который тестирует работу алгоритма, подавая ему мусор на вход?
R>-в нештатных ситуациях никаких гарантий нет — и анализ покрытия н юниттесты не скажут вам об этом если нет кода по обработке нештатных ситуаций
Нештатная ситуация это что? Computer on fire? Ошибка ввода-вывода? Крах ОС?
R>-написать юнит-тесты на отказ оборудования чисто физически проблематично, т.к. требует работы с железом\системными функциями через интерфейс(здравствуй куча врапперов). не говоря уж о том что код должен быть строго транзакционным (прощай vector\deque)
Отказ оборудования разный бывает. Если это горелая память, то тут нечего и тестировать, как оно упадет, даже ЕМУ не известно. Если это отказ периферии, то это должна быть штатная ситуация для софта, но в любом случае это уже далеко не юнит-тест, если тестируется работа с реальным железом.

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

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

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

IS>переключается только в приделах файлов самой студии, умело обходя Tool Windows. Чтобы переключиться на Tool Window (которые обычно не на основном мониторе) придется ткнуть мышой в название окна в Ctrl-Tab списке а потом снова ткнуть что бы через секунду ткнуть мышой в него уже на другом мониторе (а иначе как ?). Так что мыша это пока еще необходимое дополнение к клаве, во всяком случае в студии. (хотя я на ++ах давно не пишу — и джЫдайские навыки программированивая почти утратил)
Если мы про 2005ую то после того как нажал Ctrl-Tab и держишь Ctrl работают стрелочки...

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

Или скажем у меня была задачка по не тривиальной обработки сложных структур данных.
Как написать для этого юнит тест я так и не придумал.
Единственное что пришло в голову это дампить эти структуры в очень не маленький текстовый файл, отсмотреть этот файл глазками, и положить в svn. Далие при помощи svn смотреть что меняется.
Причем файликов таких было много и каждый из них был в разы больше чем весь код.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

S>>ну эт вы батенька загнули, таких не берут. дебагать точно прийдётся на целевой платформе.
S>>попробуй ещё NetBeans. но вобщем в любом случае VC лучьший.

__>По поводу NetBeans и Линукса. К нему еще что-то надо чтобы писать на С++.

здесь

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

M>кто без VS как без рук?

Для моего проекта вполне хватило Magic C++.

S>а вообще vs это наркотик, а наркотики вроде как вредны.

вот я щас занимаюсь мазохизмом в Eclipse чтобы отучиться

. хотя какое-то подобие ассиста там есть

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Я б не взял. Сразу заметно, что человек крайне мало работал именно с Линуксом, общий опыт может быть и велик.
При наличии общего опыта и светлой головы освоить линукс или что либо другое не составляет труда. Вобще.
Это не сложнее чем освоить какую либо билиотеку с которой никогда не работал.
А вот найти человека с опытом и светлой головой... это серьезная проблема...

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

KP>рекомендую перед написанием ответа, прочитать самую верхнюю тему и только потом отвечать.
Я читал.
А вот ты делаешь совершенно странные и далеко идущие выводы.
В конторе где я сейчас работаю разработка (за не большим исключением) идет под линукс.
Многие (включая меня) пришли с винды (я до этой работы линух только пару раз видел) и используют связку билдсервер + самба + SSH + VC++.
Никаких проблем с разработкой чисто линуксовых (крассплатформенность не нужна) программ нет.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

L>>1.Регулярные выражения.

NBN>Расшифруй. Я достаточно часто использую рег. выражения в студии для поиска и замены.

чтобы не быть голословным, пример глобальной замены:
Студия:
Ctrl-H. Клик на "use regex". Клик в первом поле ввода. Печатаем паттерн. Tab дважды или клик во втором поле. Печатаем замену. Таб несколько раз или клик на кнопе "Replace all".
И никак не выбрать предыдущее выражение одним действием, зато накликаешься вдоволь

Vim:
Esc
:1,$ s/что меняем/на что меняем/$ <Enter>

прошу отметить, без отрыва рук от клавиатуры.

просмотреть предыдущую команду: Esc : и вверх

Да, нужно один раз напрячь мозги, но после небольшой практики все эти команды выполняются на уровне моторики, и просто не задумываешься. Потом в студии приходится себя отучать от Esc :wa

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

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

Лично мне не важно, понятен ли интерфейс любому, кто видит его в первые. Важно понятен ли он мне и насколько удобен в использовании. На данный момент, возможности которые предоставляет Emacs превосходят возможности VS и мне этого достаточно для выбора редактора кода. Хотя сам начинал с VS и тоже был очень доволен предоставляемыми возможностями редактирования. Только вот постепенно изобили окон стало раздражать, лазить за мышкой стало лень, а настроить все полностью на клавиатуру в студии довольно проблематично.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AJD>Чем описание процесса сборки с помощью make лучше чем описание файла в проекте?

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>А это иррелевантно. Юнит-тесты показали, что в вашем коде все все еще ОК, но Васина либа косячит.
И? Проблема есть. Ее необходимо исправить.
А кто там накосячил это дело десятое.

L>А Вы предпочитаете оставить утечку памяти?
Я предпочитаю найти ошибку, пропатчить либу и отправить патч автору.
Ибо мне нужна система которая работает, а не стоять и крчать "Я тут не причем! Это все Вася!".

WH>>2)Или найдем что-то лучше.
L>Вариант.
Не вариант. На аналоги смотрели когда выбирали либу. Они еще хуже.

L>Знаешь, когда я пишу код, у меня первая мысль "а как я его буду тестировать". Применяя такой подход, можно половину намеченного кода, как говрят математики, свести к предыдущей задаче, т.е. использовать код, уже написанный для чего-то еще и соответственно уже оттестированный. Более того, если код таков, что натянуть на него юнит кажется невозможной или очень сложной задачей, это однозначный показатель того, что коду нужен рефакторинг.
Иногда не код такой. А задача такая.
Например у тебя на входе есть огромное дерево. И на выходе дерево но еще больше.
Писать код который сравнивает результат с тем что ожидалось?
Но это десятки если не сотни килобайт кода на каждый тест.

L>Я тебе сейчас одну обидную вещь скажу, но советую над ней подумать. Если ты не понимаешь, как протестировать свой собственный код, ты не понимаешь как он работает.
Я просто не хочу писать метры кода на ровном месте.
Ибо в них тоже может быть ошибка.

L>Подобные вещи покрываются автоматическими тестами на раз.
Ага... накатаем сотню другую килобайт исходников на каждый вариант...
Не проблема...

L>Вот когда отрастает необходимость тестировать что-то сетевое и проверить, а что, если "Вася Пупкин, разжалованный в уборщики, выдернет сетевой кабель", приходится подумать подольше. Хотя это тоже реализуемо.
Это гораздо проще чем сидеть и долбить ручками код который проверяет огромное дерево.
Это я тебе говорю как человек у которого в тз одним из первых пунктов идет: "Кластер должен работать если чать кластера физически выдет из строя."
И мои кластеры работают.

Так чем же плох вариант: Написать, отладить, сделать кучу дампов, отсмотреть их на предмет совпадения с тем что ожидали. После чего засунуть эти дампы в svn и автоматически находить регрессии.
Ы?

Кстати еще одна задача которую не понятно как тестировать: Автоматическое улучшение изображений.
Результат совершенно субъективен.
Объективные метрики полностью отсутствуют.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

gdb и его GUI расширения вам помогут в Linux.
WinDbg под Windows тоже все это умеет.

ну и логирование никто не отменял.

На мой взгляд, зависимость человека от какой-либо оболочки говорит о ограниченном количестве задачь которые он решал. К примеру, многие задачи отладки просто не могут быть решены из VC. Хотя, надо признать, различные рюшечки в VS2005 смотрятся красиво.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

AJD>Настоящие перцы в блокноте (или аналоге) код пишут.

а отлаживают в уме

... << RSDN@Home 1.2.0 alpha rev. 676>>

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

A>1)профессионалу все равно в чем писать код. хоть в ноутпаде.
Обоснуй, пожалуйста.

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

DB>Здесь идет речь не об "общем опыте", а вполне конкретных должностях и навыках.
При наличии общего опыта эти твои конкретные навыки легко приобритаются по ходу изучения проекта.
А изучение проекта происходит в любом случае.

Наличие конкретных навыков плюс для кондидата.
Но это и близко не решающий фактор.

DB>Готовы ли вы к тому, что человек бедет за ваш счет заниматься изучением? В то время как можно найти человека со знаниями технологий.
Да. Ибо найти внятного человека это уже удача. Уж больно их мало.
А знает он линух или нет вопрос десятый.

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

DB>Конечно "светлую голову" взяли бы и без навыков, но для этого ее свечение ни у кого не должно вызывать сомнений, а такое большая редкость.
А кому нужна голова которая не светится?
Ибо за этой не светящейся головой потом придется разгребать...
Видел я таких не светящихся в работе... потом весь их код шол в мусорку.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

A>>>1)профессионалу все равно в чем писать код. хоть в ноутпаде.
AJD>>Обоснуй, пожалуйста.

AZ>Профессионалы пишут код при помощи головы. Пацаны типа machine3000 — при помощи Visual Studio.
AZ>Без автокомплита жить можно, и даже без подсветки синтаксиса, а вот без головы совсем хреново, приходится рассчитывать на помощь IDE

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

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

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

L>>До ViM редактору студии как до Парижа ползком из Усть-Мухосранска.
A>Ты когда последний раз студию с поставленным Visual Assist-ом наблюдал?
[стеб моде он]
О, многомудрый Anatolix, спасибо тебе, что открыл глаза на истину!
[стеб моде офф]

Анекдот про устриц пересказывать не надо?

Современный ViM безо всяких костылей дает дикую фору редактору Студии пусть даже и с Ассистом. По юзабилити студии не догнать vim никогда, ибо слишком много вещей требуют гуевой мышевозни, и это принципиальный недостаток.
Кроме того, мне все интересно, когда же наконец студийный редактор начнет поддерживать регулярные выражения?

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

L>>Современный ViM безо всяких костылей дает дикую фору редактору Студии пусть даже и с Ассистом. По юзабилити студии не догнать vim никогда, ибо слишком много вещей требуют гуевой мышевозни, и это принципиальный недостаток.
C>ROTFL!
Ну ткни что ли неуча в какой-нить FM, где, к примеру, сказано, как в студии моментально перепрыгнуть на парный открывающий/закрывающий символ? В виме — % (подозреваю, что для этого таки есть какая-то особенно извращенная распальцовка, да вот не нашел нигде)

C>Я долго пытался допинать ViM до кондиции — не получилось. Даже отладчик нормально не прикручивается. Но самое отстойное — ViM остался в прошлом веке. Он просто работает с текстом, а VisualStudio для C# (и Vassist для С++) понимают семантику программ.
Понятно, Вим ниасилил

Вим, действительно, сам по себе работает только с текстом. Но он умеет делать это на отлично.

Отладчик, кстати, привинчивается. Только не помню как, я отладчиком не пользуюсь (ужас, правда?)
C>Что касается мыши — я ее вообще почти не трогаю в VS. Для чего она там нужна?
А было бы интересно посмотреть на запись рабочего дня студийного программиста без мыши, кстати.

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

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

WH>>>alt + a
L>>Попробуй, к примеру, сделать это в русской раскладке. Особенно с установленным ассистом. Результат удивит.
C>А команды ViMа уже у нас тоже в русской раскладке работают?
Сюрприз?
C>Проверил с Assist'ом — что я должен был увидеть?
У меня меню Ассиста вылезает. Ку?

И вобще, пустой это треп — каждый кулик свое болото хвалит.

Но, прошу прощения, системно программировать под линух, ничего, кроме студии не зная — это нонсенс.

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

Q>Не надо плакать, надо читать и думать — Windows платформа.
Я в отличии от некоторых не читал, а писал под это дело...
Реальная разработка на MFC и .NET имеют настолько мало общего что тут даже говорить не о чем.
Единственное когда там есть что-то общее это когда нужно както не тривиально захачить WinForms.

Q>Ну то-то и видно. Если не хватает желания научиться использовать стандартный редактор под Unix, то что же говорить тогда о знании sed, awk, ksh scripts, разных utilities и других страшных слов. Без этих инструментов под Unix жизнь сложна и неприятна.
А кто сказал что я их не знаю?
Я сказал что не хочу менять студию на vim.
Остальное придумал ты.

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

C>>>Проверил с Assist'ом — что я должен был увидеть?
L>>У меня меню Ассиста вылезает. Ку?
C>Странный у тебя Ассист.
С официального сайта, между прочим.
L>>И вобще, пустой это треп — каждый кулик свое болото хвалит.
C>Проблема в том, что я уже очень долго ищу нормальную среду для разработки под Линукс. Так ничего нормального и не нашел.
Под винду тоже из не густо, по большому счету.
C>"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.

Есть. Только зачем?
L>>Но, прошу прощения, системно программировать под линух, ничего, кроме студии не зная — это нонсенс.
C>Я вот в Студии пишу ядерные модули для Линукса и системный софт (компилирую через SSH, проект монтирую с помощью SMB). VAssist прекрасно понимает системные заголовки Linux'а и делает нормальный autocomplete.
Интересно, господин хороший, а какой такой отладчик Вы умудрились интегрировать со студией, да так, что можете аж ядерные линуксовые модули отлаживать.. из-под винды-то?
Осетра-то урежь.. (С)

Я правильно понимаю, что у тебя такая схема — проект сидит на целиком на линух боксе, но исходники ты редактируешь по сети(!) с виндовой машины (!) через самбу (!), а для компиляции у тебя открыт шелл (впрочем, это можно прикрутить к студии)? Ну и где тут "интеграция с отладчиком"? Ты используешь студию исключительно как редактор кода, причем далеко не самый лучший. Это даже не "стоя и в гамаке", это какой-то гораздо более экзотический случай.
You've made my night

(про себя) И эти люди запрещают нам ковыряться в носу...

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

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

DB>>Вот и отлично. У вас одни проблемы, у других — другие. Для вас знания linux не критичны, вы и в названии вакансии о linux небось не пишите. Но если другие об этом пишут значит именно это и надо.
WH>Если в вакансии написано линукс то это значит что разработка будет под линукс.
WH>И больше ничего.

А если написано С++ то это означает что разработка на С++ и больше ничего?

WH>А разобраться с линухом не сложенне чем с любой другой библиотечкой. Особенно при наличии общих знаний. WH>Ибо с точки зрения изучения нет никакой разници между функциями библиоткеки и функциями ОС.

WH>Это я тебе говорю как человек который пришол с винды и сходу начал писать линуховые кластерные решения.
WH>Проблем было много и разных но ни одна из них не была связана с не знанием API линуха.

Хм.. Что такое API Линуха?

WH>И уж точно небыло никаких проблем с освоением коммандной строки.
WH>Это при том что до этого линух я видел пару раз у знакомх на компе.

Знаем мы таких перебежцев.

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

AZ>Сколько win32 программеров могут объяснить процесс линковки? Один знакомый мне знакомый впал в глубокий ступор, когда проект отказался линковать либы с приложеним — простейщий вопрос типа unresolved symbol или неправильный тип библиотеки — и все... приплыли
Я думаю большинство программеров которые работают с С++. VB/C#'щиков такие вещи не волнуют

.

AZ>Нет. Совсем хреново с головой у того, кто не может собрать проект без IDE
А нафиг оно надо большинству, а особенно тем кто не занимается кросс-платформенной разработкой? Чем описание процесса сборки с помощью make лучше чем описание файла в проекте?

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

M>Здравствуйте, kaa.python, Вы писали:

KP>>Возможно я такой извращенец, но последнее время в процессе осваивания Emacs-а мне нравится им пользоваться все больше и больше. Как под Linux, так и под Windows.
KP>>Есть все что необходимо для комфортной работы.

M>Такие интерфейсы хороши для повседневной работы узкоспециализированного профессионала. Только навыки работы с ними долго приобретать и легко утратить, если какое-то время не пользоваться. Интерфейс с человеческим лицом должен быть понятен любому, кто видит его хоть впервые, если он знает соответствующую предметную область.
Есть только один интуитивно понятный интерфейс.. дальше рассказывать?

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

C>Поработай c IDEA/Eclipse для Java — чтобы понять КАКОЙ должна быть настоящая IDE. Потом посмотри VAssist+MSVS в качестве бледного приближения к настоящей IDE. Потом посмотри на Emacs/ViM.

я работал с кучей разных IDE: MSVC 6 + VA, MSVS 2005 + VA, Eclipse, SlickEdit, Emacs (ViM не осилиил). Единственный заслуживающий внемание радектор (кроме Emacs) был SlickEdit.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>да и как. к примеру, удалить весь текст с текущей позиции до конца строки (файла) или скопировать 5-6 (100-200) строк текста одним махом, не нашел

L>Вот обратите внимание — я одинаково успешно работаю как в одной, так и в другой системе.

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

WH>>>home, home, shift + стрелочки или pg up/pg down и выделяешь сколько нужно.
L>>считая в уме? Эргономично, ничего не скажешь.
L>>(vim)100yy — скопировать 100 строк
L>>Попробуйте Ваши шорткаты на клавиатуре ноутбука, кстати. Особенно когда умеете печатать вслепую.
TL>А еще на КПК тоже не слишком удобно получается...

Там тоже нет интегрированного отладчика, между прочим

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

TL>Это какой-то приговор?

Я бы сказал, диагноз

WH>>>Может все же объяснишь?
L>>Очень трудно объяснить это человеку, который к аргументам глух как стенка.
TL>Это точно.

WH>>>А то ты так ничего и не назвал. Все что назвал есть в студии.
L>>Приведенные выше шорткаты. Они есть, только использовать их банально неудобно.
TL>Чуть выше Вы сами заметели сильную сторону Юникса, когда более сложные вещи "собираются" из простых — "студия" реализует именно этот принцип — навскидку, почему для удалению до конца строки и до конца файла регистр команды разный — я, как простой гуевый мышевозила, логичных причин не вижу.

У "студии" совершенно логичное объединение команд навигации по тексту (End, Ctrl+End) с командами выделения (нажатый Shift) и последующими командами удаления или копирования — или, например, замены только по выделенному фрагменты — с подключением регулярных выражений или без.

У странных и нелогичных на первый взгляд команд vi есть огромное преимущество — после второго применения они запоминаются на уровне моторики и потом выполняются без отрыва от производства, так сказать. Для любых шорткатов студии необходимо "переключение контекста", т.е. как максимум отрывать внимание, а как минимум — переносить руки. Опять же, не заточена она на использование клавиатуры только, приходится и мышой возить.
TL>Задача скопировать 100 строк несомненно интересна — а какое-нибудь практическое примение у нее есть?

Это синтетический пример. Более реальный — видишь три/пять строк кода и одним махом их копируешь/удалаяешь.
Я, кстати, даже не заикнулся про повтор последней команды. В vim жмешь "." и получаешь повтор последней команды редактирования, как то регексп, копирование/удаление/вставка. Это очень сильная вещь, между прочим (не надо сравнивать с записью макросов, плиз).
WH>>>Все что ты продемонстрировал это не знание того как работать в студии.
L>>Заметь, это незнание того, как эффективно работать с редактором студии. Я это и не отрицаю хотя бы потому, что он нихрена не эргоноичный.
TL>Да, кроме эффективной работы с редактором исходных вещей "студия" оснащена еще туевой хучей инструментов, однако же лично Вам...
L>>>>Ау, неужели не интересно, как люди без этой интеграции живут, умудряясь создавать стабильные и надежные системы?
WH>>>Пальци...
L>>Пальцы это "дайте мне студию, и неважно что пишем под [unix|VxWorks|symbian...], бо без интеграции с отладчиком и жизнь не мила".
TL>... ни интегрированный отладчик, ни прочие "излишества" совершенно не интересны — о чем спор?

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

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

WH>>Пальцан...
L>Мои коллеги и заказчики имеют слегка другое мнение.
Ну что поделать если ведешь себя именно так...

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

WH>>>shift + end, del
L>>(vim)D
WH>Ой лукавишь...
WH>Воспроизвожу последовательность находясь в режиме редактирования:
WH>Esc — Переход в коммандный режим. Зачем курсор сдвинуля на одну позицию влево?
WH>стрелка в право

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

WH>shift + d — Удаляем. Опять курсор уехал

WH>i — Переход в режим редактирования
WH>стрелка в право

Ха-ха, знание Vim налицо. Все это делается командой C.

WH>В студии как и в большинстве других виндовых редакторов два нажатия.
WH>Причем это две ортогональные операции. Выделение и удаление. Те их можно комбинировать с другими операциями.

Учитывая, что такие удаления производятся при перемещении по тексту, а не редактировании, студия сосет по полной. Гораздо быстрее пройтись по строкам нажимая D, чем постоянно распальцовываться на s-e, del.
Что касается ортогональности, то в Vim она присутствует в гораздо большей мере. Команды типа d и c комбинируются с командами перемещения и позволяют указывать количество повторений перемещения и самих команд.

L>>(vim)dG
WH>Таже байда.

ха-ха.

L>>считая в уме? Эргономично, ничего не скажешь.
L>>(vim)100yy — скопировать 100 строк
WH>Я не могу вспомнить ни одного случая когда мне нужно было скопировать N строк когда N я знал зарание.
WH>Я всегда знаю что мне нужно скопировать от сюда до туда. Если текста много то использую page up/page down и потом подруливаю стрелочками.
WH>А сколько там строк я никогда не задумываюсь. Мне что делать больше нечего чем строки считать?

Да, способ выделения достойный. Стоит чихнуть не вовремя и выделяй все снова.

L>>Заметь, это незнание того, как эффективно работать с редактором студии. Я это и не отрицаю хотя бы потому, что он нихрена не эргоноичный.
WH>По сравнению с вимом верх эргономики.

Вам бы в Петросяны.

WH>Но вот редактор в студии банально удобней.
WH>И менять его на линуховые поделки в которых ради примитивного действия нужно плясать с бубном (см выше) я не намерен.

Vi затачивался под удобство программистов еще когда Билл Гейтс окошки у Эппл воровал.

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

KP>все-таки стоит признать — удобство вещь крайне субъективная. и когда ВСЕ редакторы ведут себя одним способом, а ОДИН другим это не совсем удобно и надо иметь крайне веские причины чтоб с этим одним разбираться. хотя, в определенных случаях время потраченное на разбирательство покроется сполна.

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

landerhigh пишет:
>
>> > Может, для начала следует научиться писать код так, чтобы не было
>> > необходимости в отладчике?
> Хинт: юнит-тесты.
Хинт: не все, что тебе придеться писать можно покрыть юнит-тестами.

Posted via RSDN NNTP Server 2.0

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

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

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

C>>>VisualStudio+VAssist работают уже с программой — они понимают структуру кода. Это уже совершенно другой уровень.
L>>Ага. Только completions в комментариях не работают (подумайте дважды, перед тем, как спрашивать зачем это надо, ладно?) Да и при программировании шаблонов толку от них маловато.

TL>Ну если так — то конечно. Правда в комментариях и подсветки синтаксиса нет...

Лично я тупо пишу код, а потом нужное комментирую...

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

TL>"Иксоиды" — это все же реально "клан высших" — ну по крайней мере по их мнению. Правда не все "иксоиды" его придерживаются — встречаются и обычные люди, наплевательские относящиеся к "незнанию команд vim" каждым первым незнакомым или даже знакомым человеком.

TL>А вот с первыми, с "несущими Слово Его" — общаться действительно трудно...

О, да, в общении с отдельными индивидууами иногда думаешь, что им сам Билли платит за проповеди

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

AJD>ИМО, странная аналогия. Т.е. если в хорошем IDE есть мощные средства автоформатирования, рефакторинга (а в хорошем IDE они должны быть), то это приводит к плохому коду?

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

kaa.python wrote:
> C>Драйверы (и ядерный код вообще)
> если драйвер написан с умом, то всю логику из него можно покрыть
> тестами. взаимодействие с железом не уверен.
В драйверах очень сложно тестировать "крайние точки". Типа поведения
драйвера при hibernate. Или при резком выдергивании устройства из порта.

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

> C> код для встроеных систем.
> тоже никаких проблем. логика с легкостью делается кросс-платформенной и
> тестируется на Win или Linux.
Ха. Ха. Ха.

Ты можешь мне показать, как я могу прикрутить систему датчиков движения,
требующий 30 GPIO входов к обычному PC с Windows? Да, мне бы еще
хотелось поддержку DMA. А, пока не забыл — для устройства нужны еще
очень точные realtime-прерывания, иначе там переполняется внутренний
буффер и теряются данные.

> C> Ну и банальный GUI.
> первый случай когда вы сказали по делу. но и тут, если ГУИ написан
> грамотно, то отдельно стоящую бизнес-логику протестировать можно.
Вот только "бизнес-логика" самого GUI никак не тестируется. Мы пробовали
несколько UI-тестеров (Marathon, GUI Dancer, SwingUnit) — они требуют
больше времени, чем экономят.

> C>Часто стоимость test harness будет превышать стоимость всего проекта в
> разы.
> часто стоимость проекта написанного по принципу "надо копать и как можно
> скорее" в разы превышает стоимость проектов в которых есть нормальное
> покрытие кода тестами.
Ага, и часто эти "проекты с нормальным покрытием" находятся в области
фантастики.

Posted via RSDN NNTP Server 2.1 beta

The Lex пишет:
>
> L>Ради интереса, посмотрел бы, как это делает LaTeX и как выглядит
> результат его работы.
>
> Я смотрел — не ради интереса. А Вы смотрели как это делает Word?
А самим не надоели такие споры. Ворду вордово, теху техово.
А так споры напоминают, вы пробовали микроскопом гвозди забивать, а вы
пробовали в линзу бактерию увидеть.

Posted via RSDN NNTP Server 2.0

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

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

L>>То, что вы делаете в отладчике, легко автоматизируется юнит тестом, который затем включается в состав ночного билда и когда очередной Вася Пупкин организует в Вашем давно отлаженном коде очередной расстрел памяти, Вы, вместо того, чтобы с отладчиком наперевес трассировать всю систему (недельку-другую), просто выдадите люлей Васе.
WH>А если этот Вася автор сторонней либы? И живет этот Вася на другом конце планеты?
А это иррелевантно. Юнит-тесты показали, что в вашем коде все все еще ОК, но Васина либа косячит.
WH>1)Только не надо гнуть пальци и говорить что сейчас мы это поделье быстреньке перепишем.
А Вы предпочитаете оставить утечку памяти?
WH>2)Или найдем что-то лучше.
Вариант.

WH>Или скажем у меня была задачка по не тривиальной обработки сложных структур данных.
WH>Как написать для этого юнит тест я так и не придумал.
Слово "не могу" живет на улице "не хочу".
Знаешь, когда я пишу код, у меня первая мысль "а как я его буду тестировать". Применяя такой подход, можно половину намеченного кода, как говрят математики, свести к предыдущей задаче, т.е. использовать код, уже написанный для чего-то еще и соответственно уже оттестированный. Более того, если код таков, что натянуть на него юнит кажется невозможной или очень сложной задачей, это однозначный показатель того, что коду нужен рефакторинг.

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

WH>Единственное что пришло в голову это дампить эти структуры в очень не маленький текстовый файл, отсмотреть этот файл глазками, и положить в svn. Далие при помощи svn смотреть что меняется.
WH>Причем файликов таких было много и каждый из них был в разы больше чем весь код.
Подобные вещи покрываются автоматическими тестами на раз.
Вот когда отрастает необходимость тестировать что-то сетевое и проверить, а что, если "Вася Пупкин, разжалованный в уборщики, выдернет сетевой кабель", приходится подумать подольше. Хотя это тоже реализуемо.

landerhigh wrote:
> C>Видимо, ты не работал с большими проектами. У меня очень часто при
> изменении твоего кода ломается какая-то другая библиотека.
> Индикатор никудышнего тестирования кода.
Еще раз напомню — код библиотеки покрыт тестами почти на 100% (по
результатам test coverage тулзов). Просто бывают достаточно интересные
случаи с конкуррентными изменениями, которые никто не предусмотрел заранее.

> C>Юнит-тест позволяет диагностировать регрессии. С ними проблем нет,
> проблемы с *новыми* ошибками.
> Индикатор никудышнего тестирования кода.
Угу. Вот бы мне еще кто пример замечательно протестированого кода
показал, который делает то же самое. Я бы свою поделку нафиг выбросил.

> Попробуйте изменить подход к "покрытию юнит-тестами".
Куда? В третий раз напомню — код библиотеки почти на 100% покрыт
тестами. Почему же мне не помогает эта магическая серебряная пуля?

> C>После того, как ошибка найдена — для нее пишется юнит-тест, но саму
> ошибку-то надо сначала найти. Отладочная печать для этого жутко неудобна
> — приходится *перекомпилировать и перезапускать* приложение, если нужно
> добавить новую точку наблюдения.
> Бывает. Еще можно лог к программе приделать.
Приделан. Ничерта не помогает. Тем более, что писать в лог сложные
графовые стркутуры — это еще то занятие.

Posted via RSDN NNTP Server 2.1 beta

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

AJD>>Если для документирования, а-ля doxygen, то это все шоткатами генерится, включая имя и параметры. А еще зачем?
L>Банально в блоке \code..\endcode написать пример использования.

Обычно я этот кусок кода беру уже из готового рабочего примера, поэтому необходимость как-то не возникает

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

M>кто без VS как без рук?

Нет.

кто без VS как без рук?

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

M>кто без VS как без рук?
А как он работать будет?

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

M>кто без VS как без рук?

А как ты на Линуксе собираешься пользоваться VS?

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

Q>А как ты на Линуксе собираешься пользоваться VS?

ну какие наивные. в VS под виндой редактируеш, компилируеш на билд-сервере.

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

M>Поэкспериментировав с KDevelop, Eclipce и gdb пришёл к выводу, что легче под виндой кроссплатформенно проги писать и отлаживать, а на Unix один make запускать.

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

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

M>>Поэкспериментировав с KDevelop, Eclipce и gdb пришёл к выводу, что легче под виндой кроссплатформенно проги писать и отлаживать, а на Unix один make запускать.

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

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

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

AJD>Здравствуйте, kaa.python, Вы писали:

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

AJD>Настоящие перцы в блокноте (или аналоге) код пишут.

А самые настоящие в copy con hello_world.cpp

Тоже столкнулся несколько лет назад с проблемой нормальной IDE, именно IDE, а не редактор кода, на юникс/линукс.
До сих пор вопрос открыт

По сравнению с VS все остальное отстой. Но приходиться жрать этот чертов кактус

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

AJD>Настоящие перцы в блокноте (или аналоге) код пишут.

вроде я это не говорил

хотя, и блокнот, к примеру GEdit или colorer очень даже ничего.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>ну какие наивные. в VS под виндой редактируеш, компилируеш на билд-сервере.

И что, специально для таких editor-challenged господ покупать лицензии на ВС и Винду?

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

_M_>а отлаживают в уме

На то они и перцы, что пишут код без ошибок. А если не работает, так это фича

KP>Честно сказать, человек, который без VS как без рук, у меня и на Win32 вызвал бы опасение в роли Senior Developer.

ты что, а как код без подсказки писать? в VS же автокомплит есть. а Сениоры не обязаны помнить синтаксис

M>кто без VS как без рук?

тема конечно стебная.
но если серьезно то:
1)профессионалу все равно в чем писать код. хоть в ноутпаде.
2)выбор средств разработки это как правило общекомандная политика.

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

M>>кто без VS как без рук?

A>тема конечно стебная.
A>но если серьезно то:
A>1)профессионалу все равно в чем писать код. хоть в ноутпаде.
A>2)выбор средств разработки это как правило общекомандная политика.

Исходя из этого все на Блокнот!!! Да и прикрутить к нему систему контроля версий!!! А... Так можно же в WORD. Во!!!!!

A>>1)профессионалу все равно в чем писать код. хоть в ноутпаде.
AJD>Обоснуй, пожалуйста.

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

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

M>кто без VS как без рук?

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

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

_M_>>а отлаживают в уме

NBN>Настоящие перцы, пишут на С, в блокноте, отлаживаются в уме, ошибок не совершают и не существуют

аццкие программисты

... << RSDN@Home 1.2.0 alpha rev. 676>>

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

M>кто без VS как без рук?
В своё время, я плювался также на невижуалы. В принципе нашёл компромис. Кодил в вижуале, подписал скрипты что б по ссш компилятор запускал юниксовый(файлы открывал по самбе), а вижуал даже у себя в окошке выдавал, что ответил юниксовый мэйк (в идеале ходят слухи даже можно сделать, что бы распознавал строку и автоматом можно было бы на нужную ошибку перескочить). Автокомплит — не помню был ли(а юниксовские библиотеки уж точно нет). Но так хоть редактор вменяемый был. Отладка, естественно, уже велась в юниксах. Но для этого надо пара машин, либо виртуалки.
PS. А как я управлял консольным медиа плеером по ссш, по причине отсутствия клавиатуры на bsdшной машине, но наличию звуковухи, вообще отдельная эротишная история

M>кто без VS как без рук?

Я б не взял. Сразу заметно, что человек крайне мало работал именно с Линуксом, общий опыт может быть и велик.

Мой совет — поставь Kate (kate.kde.org, может входить и в линуксные дистры), и приноровись к ней. Это процентов на 99 клон MSVCшного редактора под KDE, т.е. и под Линукс, и под FreeBSD.

После этого говори, что пользуешься Kate.

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

Совершенно не согласен. У почти каждого есть свой любимый редактор, включая, например, американских DDK MVPs — вряд ли они слабые разработчики.

Другое дело, что у некоторых _этот редактор кроссплатформенный и опен-сорсный_.

A>1)профессионалу все равно в чем писать код. хоть в ноутпаде.

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

A>2)выбор средств разработки это как правило общекомандная политика.

Редактора? никто не запретит _редактировать_ код в том, что тебе нравится, если оно бесплатное и/или опенсорсное. Ставишь себе на машину и вперед.

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

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

A>>>>1)профессионалу все равно в чем писать код. хоть в ноутпаде.
AJD>>>Обоснуй, пожалуйста.

A>>время на освоение очередного инструмента это мизер в общей структуре временных затрат.
A>>я недавно с ClearCase разобрался за день, хотя до этого ее в глаза не видел.

NBN>Ну время освоения действительно мизер. Но вот время работы в инструменте — уже нет.
NBN>Я топор тоже могу быстро освоить, но предпочту использовать бензопилу.

Для колки дров топор (колун) таки лушче, да и вероятность выстрели.. отпилить себе ногу пониже будет

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

A>>>время на освоение очередного инструмента это мизер в общей структуре временных затрат.
A>>>я недавно с ClearCase разобрался за день, хотя до этого ее в глаза не видел.

NBN>>Ну время освоения действительно мизер. Но вот время работы в инструменте — уже нет.
NBN>>Я топор тоже могу быстро освоить, но предпочту использовать бензопилу.

L>Для колки дров топор (колун) таки лушче, да и вероятность выстрели.. отпилить себе ногу пониже будет

Отсюда вывод: своему инструменту — свои задачи.
Хеловорлд легко в блокноте написать, а если нужно что-то большое и системное — то без вижалки, как без рук.

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

NBN>>>Я топор тоже могу быстро освоить, но предпочту использовать бензопилу.
L>>Для колки дров топор (колун) таки лушче, да и вероятность выстрели.. отпилить себе ногу пониже будет

NBN>Отсюда вывод: своему инструменту — свои задачи.
NBN>Хеловорлд легко в блокноте написать, а если нужно что-то большое и системное — то без вижалки, как без рук.

Вот недавно сдали большой и системный комплекс контроля автомобильным трафиком. Без вижуалки. Да еще и под linux.
Мы что-то сделали не так?

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

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

WH>Ты в самом деле думаешь что линух это что-то такое с чем нормальный разработчик не сможет легко разобраться?

рекомендую перед написанием ответа, прочитать самую верхнюю тему и только потом отвечать.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

M>>кто без VS как без рук?
0> Автокомплит — не помню был ли(а юниксовские библиотеки уж точно нет).
не понял? как это нет? а потянуть себе на машину ликусовые хидера и натравить ни них асиста?

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

A>>>1)профессионалу все равно в чем писать код. хоть в ноутпаде.

A>время на освоение очередного инструмента это мизер в общей структуре временных затрат.
A>я недавно с ClearCase разобрался за день, хотя до этого ее в глаза не видел.

И что с того? То что человек может в чем-то быстро разобраться совсем не означает, что ему все равно на чем писать.

>A>>1)профессионалу все равно в чем писать код. хоть в ноутпаде.
> AJD>Обоснуй, пожалуйста.
>
> время на освоение очередного инструмента это мизер в общей структуре временных затрат.
> я недавно с ClearCase разобрался за день, хотя до этого ее в глаза не видел.

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

Posted via RSDN NNTP Server 2.1 beta

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

MSS>>Я б не взял. Сразу заметно, что человек крайне мало работал именно с Линуксом, общий опыт может быть и велик.
WH>При наличии общего опыта и светлой головы освоить линукс или что либо другое не составляет труда. Вобще.
WH>Это не сложнее чем освоить какую либо билиотеку с которой никогда не работал.
WH>А вот найти человека с опытом и светлой головой... это серьезная проблема...

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

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

попробую объяснить понятнее.
Senior Linux C++ Developer это не сказать что рядовой разработчик. Этот человек должен обладать глубокими знаниями системы Linux. Этот человек должен быть в состоянии помочь решить проблемы менее квалифицированному специалисту. получить глубокие знания системы не работая с ней достаточное время проблематично. Тогда какой смысл в Senior Linux C++ Developer, если он даже работать с целевой платформой нормально не умеет?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

WH>Наличие конкретных навыков плюс для кондидата.
WH>Но это и близко не решающий фактор.

DB>>Готовы ли вы к тому, что человек бедет за ваш счет заниматься изучением? В то время как можно найти человека со знаниями технологий.
WH>Да. Ибо найти внятного человека это уже удача. Уж больно их мало.
WH>А знает он линух или нет вопрос десятый.

Тогда зачем в вакансии "Senior Linux C++ Developers" присутствует слово Linux?

DB>>Конечно "светлую голову" взяли бы и без навыков, но для этого ее свечение ни у кого не должно вызывать сомнений, а такое большая редкость.
WH>А кому нужна голова которая не светится?

И много там вас таких светящихся?

WH>Ибо за этой не светящейся головой потом придется разгребать...
WH>Видел я таких не светящихся в работе... потом весь их код шол в мусорку.

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

KP>>попробую объяснить понятнее.
KP>>Senior Linux C++ Developer это не сказать что рядовой разработчик. Этот человек должен обладать глубокими знаниями системы Linux. Этот человек должен быть в состоянии помочь решить проблемы менее квалифицированному специалисту. получить глубокие знания системы не работая с ней достаточное время проблематично. Тогда какой смысл в Senior Linux C++ Developer, если он даже работать с целевой платформой нормально не умеет?
WH>Senior Linux C++ Developer звучит примерно также как Senior MFC C++ Developer итп.
WH>Знание линукса ничем не отличаются от знания какой либо библиотечки.

Кстати очень хорошее сравнение. Сразу в голову пришло "Visual Studio 2005 написана на .net. Может ли человек быть Senior MFC C++ Developer используя 2005 студию, или ему нужно работать на студии 6.0"

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

WH>А вот найти человека с опытом и светлой головой... это серьезная проблема...

Да не проблема это ни фига. Вопрос только денег исключительно.

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

DB>>Готовы ли вы к тому, что человек бедет за ваш счет заниматься изучением? В то время как можно найти человека со знаниями технологий.
WH>Да. Ибо найти внятного человека это уже удача. Уж больно их мало.

Это вопрос денег. Предложите больше и к вам выпускники MITа потянутся

.

WH>А кому нужна голова которая не светится?
WH>Ибо за этой не светящейся головой потом придется разгребать...
WH>Видел я таких не светящихся в работе... потом весь их код шол в мусорку.

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

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

NBN>>Настоящие перцы, пишут на С, в блокноте, отлаживаются в уме, ошибок не совершают и не существуют

A>"настоящий программист не всегда знает язык на котором он программирует"(с)классика
A>

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

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

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

L>>До ViM редактору студии как до Парижа ползком из Усть-Мухосранска.
A>Ты когда последний раз студию с поставленным Visual Assist-ом наблюдал?

А какое отношение VA имеет к VS? Сторонний плагин. Возможности VS как редактора, действительно, убоги по сравнению
и с Vim и Emacs. А так для того же Emacs есть Xrefatory, функциональность которго соответствует VA. Покупай и работай.

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

WH>>Senior Linux C++ Developer звучит примерно также как Senior MFC C++ Developer итп.
WH>>Знание линукса ничем не отличаются от знания какой либо библиотечки.

A>Кстати очень хорошее сравнение. Сразу в голову пришло "Visual Studio 2005 написана на .net. Может ли человек быть Senior MFC C++ Developer используя 2005 студию, или ему нужно работать на студии 6.0"

Чушь какая-то. Девелопер МФС и девелопер .net работают в рамках одной платформы, единого подхода. Для Unix требуются совершенно другие знания других библиотек и других подходов.

>моторном навыке — пока пальцы "заточены" под старый инструмент, на новом не работа, а мученья.

что значит пальцы заточены? клавишные комбинации ? так они в любом не самом примитивном редакторе настраиваются.

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

Q>А какое отношение VA имеет к VS? Сторонний плагин. Возможности VS как редактора, действительно, убоги по сравнению и с Vim и Emacs.
Может ты еще скажешь чего студия не умеет?
А то както голословно выглядит.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

Q>Чушь какая-то. Девелопер МФС и девелопер .net работают в рамках одной платформы, единого подхода.
MFC и .NET одна платформа...

Я плакал...

Q>Для Unix требуются совершенно другие знания других библиотек и других подходов.
Неа. Нужно умение разбираться в том что видишь первый раз.
В прочем это умение нужно всегда и везде.
Ибо по сравнению со спецификой конкретного проекта стандартные линуксовые библиотечки просто детский лепет.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

>>моторном навыке — пока пальцы "заточены" под старый инструмент, на новом не работа, а мученья.

A>что значит пальцы заточены? клавишные комбинации ? так они в любом не самом примитивном редакторе настраиваются.

Напомню — речь шла о нотпаде

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

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

Q>Чушь какая-то. Девелопер МФС и девелопер .net работают в рамках одной платформы, единого подхода. Для Unix требуются совершенно другие знания других библиотек и других подходов.

Извини за глупый и бестактный вопрос: но ты под Unix писал когда-нибудь?
(Мне просто в свое время показалось изучить unix сильно проще чем MFC, которую я так до конца и не осилил вкурить)

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

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

Q>>А какое отношение VA имеет к VS? Сторонний плагин. Возможности VS как редактора, действительно, убоги по сравнению и с Vim и Emacs.
WH>Может ты еще скажешь чего студия не умеет?
WH>А то както голословно выглядит.
1.Регулярные выражения.
2.Шаблоны для вновь создаваемых файлов. Я имею в виду неректальный способ их добавления/изменения
3.Да и собственно редактор в студии убожество то еще

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

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

NBN>>>Хеловорлд легко в блокноте написать, а если нужно что-то большое и системное — то без вижалки, как без рук.
L>>

L>>Вот недавно сдали большой и системный комплекс контроля автомобильным трафиком. Без вижуалки. Да еще и под linux.
L>>Мы что-то сделали не так?

NBN>Чтобы было ясно — я не утверждаю, что если ты программируешь под линукс — то всёравно должен сидеть в вижуалке

Это извращение

NBN>Я веду к тому, что вижалка видимо один из самых удобных интсрументов для разработки, и что пренебрегать удобными инструментами не стоит

Выбор инструмента естественно по обстоятельствам.
Да на здоровье. Вот только существуют инструменты и поудобнее студии, однако.

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

NBN>>Чтобы было ясно — я не утверждаю, что если ты программируешь под линукс — то всёравно должен сидеть в вижуалке

Это извращение

NBN>>Я веду к тому, что вижалка видимо один из самых удобных интсрументов для разработки, и что пренебрегать удобными инструментами не стоит

Выбор инструмента естественно по обстоятельствам.
L>Да на здоровье. Вот только существуют инструменты и поудобнее студии, однако.

Если можно приведи примеры. С условиями: для виндов, для плюсов, инструмент лучший Студии + VA.

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

L>1.Регулярные выражения.

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

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

L>2.Шаблоны для вновь создаваемых файлов. Я имею в виду неректальный способ их добавления/изменения

Это если можно — тоже. Я правда не так много шаблонов файлов использую (90% заголовочники и 10% проектные файлы), но в впринципе не вижу проблем увеличить количество шаблонов до произвольного количества. Шаблоны через VA.

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

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

L>>2.Шаблоны для вновь создаваемых файлов. Я имею в виду неректальный способ их добавления/изменения

NBN>Это если можно — тоже. Я правда не так много шаблонов файлов использую (90% заголовочники и 10% проектные файлы), но в впринципе не вижу проблем увеличить количество шаблонов до произвольного количества. Шаблоны через VA.

А так чтобы Add new class -> и у тебя сгенерированные файлы имеют заголовок, принятый в вашей конторе, guard macro вместо прагмы и т.п? Чтобы не ручками все это править?

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

L>чтобы не быть голословным, пример глобальной замены:
L>Студия:
L>Ctrl-H. Клик на "use regex".
Один раз. Студия запоминает настройки поиска.
Хотя лично у меня отмечены "Match case", "Match whole word" и "Search hidden text" именно это нужно в подавляющем большинстве случаев.

L>Клик в первом поле ввода.
Зачем клик? Фокус уже там.

L>Печатаем паттерн.
Как и и виме.
Причем студия подставляет туда то что под курсором или выделеное. ИМХО очень удобно. Ибо в большинстве случаев именно это и нужно заменить.

L>Tab дважды или клик во втором поле.
Зачем дважды?
Одного раза достаточно.

L>Печатаем замену. Таб несколько раз или клик на кнопе "Replace all".
Зачем?
alt + a

Далие Esc чтобы закрыть диалог.

L>И никак не выбрать предыдущее выражение одним действием, зато накликаешься вдоволь

Зачем кликать?
Стрелки работают.

L>прошу отметить, без отрыва рук от клавиатуры.
Прошу отметить я тоже.

L>Да, нужно один раз напрячь мозги, но после небольшой практики все эти команды выполняются на уровне моторики, и просто не задумываешься. Потом в студии приходится себя отучать от Esc :wa

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

L>Современный ViM безо всяких костылей дает дикую фору редактору Студии пусть даже и с Ассистом. По юзабилити студии не догнать vim никогда, ибо слишком много вещей требуют гуевой мышевозни, и это принципиальный недостаток.
ROTFL!

Я долго пытался допинать ViM до кондиции — не получилось. Даже отладчик нормально не прикручивается. Но самое отстойное — ViM остался в прошлом веке. Он просто работает с текстом, а VisualStudio для C# (и Vassist для С++) понимают семантику программ.

Что касается мыши — я ее вообще почти не трогаю в VS. Для чего она там нужна?

L>Кроме того, мне все интересно, когда же наконец студийный редактор начнет поддерживать регулярные выражения?
Так уже лет 10 вроде как.

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

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

L>>Современный ViM безо всяких костылей дает дикую фору редактору Студии пусть даже и с Ассистом. По юзабилити студии не догнать vim никогда, ибо слишком много вещей требуют гуевой мышевозни, и это принципиальный недостаток.
L>>Кроме того, мне все интересно, когда же наконец студийный редактор начнет поддерживать регулярные выражения?
WH>Все ясно.
WH>Что умеет студия и как ей пользоваться понятие не имеешь.
Все ясно.
Что умеет vim и как им пользоваться понятиЯ не имеешь.

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

C>Что касается мыши — я ее вообще почти не трогаю в VS. Для чего она там нужна?
переключаться между окнами.

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

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

L>>чтобы не быть голословным, пример глобальной замены:
L>>Студия:
L>>Ctrl-H. Клик на "use regex".
WH>Один раз. Студия запоминает настройки поиска.
WH>Хотя лично у меня отмечены "Match case", "Match whole word" и "Search hidden text" именно это нужно в подавляющем большинстве случаев.
Мы же регулярно выражаться решили, вы что? Какие "match whole word", какие "match case"? А если не надо матчить кейс? Опять щелкать?
L>>Клик в первом поле ввода.
WH>Зачем клик? Фокус уже там.
После клика на любом чекбоксе фокус улетучивается.
L>>Печатаем паттерн.
WH>Как и и виме.
в нем все, что нужно сделать — напечатать паттерн.
WH>Причем студия подставляет туда то что под курсором или выделеное. ИМХО очень удобно. Ибо в большинстве случаев именно это и нужно заменить.
Особенно, когда нужно повторить или слегка изменить предыдущий паттерн. Очень удобно, ага, когда вместо того, что тебе нужно, оно туда подсовывает то, что по ее мнению нужно.
L>>Tab дважды или клик во втором поле.
WH>Зачем дважды?
WH>Одного раза достаточно.
И кто тут хвастался, что студию знает?
L>>Печатаем замену. Таб несколько раз или клик на кнопе "Replace all".
WH>Зачем?
WH>alt + a
Попробуй, к примеру, сделать это в русской раскладке. Особенно с установленным ассистом. Результат удивит.
WH>Далие Esc чтобы закрыть диалог.
L>>И никак не выбрать предыдущее выражение одним действием, зато накликаешься вдоволь

WH>Зачем кликать?
WH>Стрелки работают.
Еще раз — открываешь другой файл и решаешь, регулярно выражаясь, повторить там то же, что сделал недавно в другом файле.
L>>прошу отметить, без отрыва рук от клавиатуры.
WH>Прошу отметить я тоже.
может быть.
L>>Да, нужно один раз напрячь мозги, но после небольшой практики все эти команды выполняются на уровне моторики, и просто не задумываешься. Потом в студии приходится себя отучать от Esc :wa

WH>А мне когда приходятся работать в виме приходится себя от студийных шорткатов отучать.
WH>Благо ничего кроме мелких патчей я там не делаю.

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

NBN>Если можно приведи примеры. С условиями: для виндов, для плюсов, инструмент лучший Студии + VA.

GNU Emacs + Xref + make файлы.
в принципе одного Emacs-а с make-ами хватит, хотя Xref, довольно приятная тулза.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Мы же регулярно выражаться решили, вы что? Какие "match whole word", какие "match case"? А если не надо матчить кейс? Опять щелкать?
Еще раз.
Если тебе нужны регулярные выражения то ты РОВНО ОДИН РАЗ ПОСЛЕ УСТАНОВКИИ СТУДИИ ВЫБИРАЕШЬ ЭТОТ ЧЕКБОКС.
Все!
Студия это запомнит.

Но лично мне в 99% нужны ровно те галочки что я написал.

А когда я работал на C# с ReSharper'ом я этот диалог вобще почти никогда не трогал.

L>После клика на любом чекбоксе фокус улетучивается.
А зачем кликать?

L>в нем все, что нужно сделать — напечатать паттерн.
А что в студии нужно что-то еще?

L>Особенно, когда нужно повторить или слегка изменить предыдущий паттерн. Очень удобно, ага, когда вместо того, что тебе нужно, оно туда подсовывает то, что по ее мнению нужно.
Стрелку вниз нажми.

L>И кто тут хвастался, что студию знает?
Мы точно о разных студиях говорим.

L>Попробуй, к примеру, сделать это в русской раскладке. Особенно с установленным ассистом. Результат удивит.
Гм. А зачем мне русская раскладка в редакторе кода?

L>Еще раз — открываешь другой файл и решаешь, регулярно выражаясь, повторить там то же, что сделал недавно в другом файле.
А в чем проблема?
Все настройки диалога сохраняются.

L>может быть.
Не может, а совершенно точно.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

WH>>Зачем клик? Фокус уже там.
L>После клика на любом чекбоксе фокус улетучивается.
Ты про hotkey'и слышал?

Жмем alt-e — включаем регэкспы. Потом жмем alt-n — переходим обратно в поле фокуса. Я обычно над такими действиями вообще не задумываюсь — Windows выделяет hotkey с помощью подчеркивания, так что даже не надо ничего запоминать.

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

WH>>alt + a
L>Попробуй, к примеру, сделать это в русской раскладке. Особенно с установленным ассистом. Результат удивит.
А команды ViMа уже у нас тоже в русской раскладке работают?

Проверил с Assist'ом — что я должен был увидеть?

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

WH>Гм. А зачем мне русская раскладка в редакторе кода?
L>>Еще раз — открываешь другой файл и решаешь, регулярно выражаясь, повторить там то же, что сделал недавно в другом файле.
WH>А в чем проблема?
WH>Все настройки диалога сохраняются.
Так уж и все? Паттерн-то студия заменяет на слово под курсором, что, несомненно, "очень удобно"

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

L>Так уж и все? Паттерн-то студия заменяет на слово под курсором, что, несомненно, "очень удобно"

1)Стрелку вниз нажми.
2)Лично мне менять что-то в паре файлов почти никогда не нужно. Как правило нужно либо менять в одном либо по всему проекту или даже солюшену.
Для этого есть ctrl + shift + h.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

L>Кроме того, мне все интересно, когда же наконец студийный редактор начнет поддерживать регулярные выражения?
Еще древняя 6 студия их поддерживала, уже скоро будет 10 лет как.

landerhigh wrote:
> Vim:
> Esc
> :1,$ s/что меняем/на что меняем/$ <Enter>

А можно еще проще — вместо 1,$ можно написать %

Posted via RSDN NNTP Server 2.1 beta

> А какое отношение VA имеет к VS? Сторонний плагин. Возможности VS как редактора, действительно, убоги по сравнению
> и с Vim и Emacs. А так для того же Emacs есть Xrefatory, функциональность которго соответствует VA. Покупай и работай.

Xrefatory — куда более тормознутая и падучая программа, чем VA. И на сложных проектах она, в отличие от VA, практически неработоспособна.

Posted via RSDN NNTP Server 2.1 beta

> Ну ткни что ли неуча в какой-нить FM, где, к примеру, сказано, как в студии моментально перепрыгнуть на парный открывающий/закрывающий символ? В виме — % (подозреваю, что для этого таки есть какая-то особенно извращенная распальцовка, да вот не нашел нигде)

Ctrl+]

Posted via RSDN NNTP Server 2.1 beta

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

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

C>>Что касается мыши — я ее вообще почти не трогаю в VS. Для чего она там нужна?
IS>переключаться между окнами.

Ctrl + Tab ?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>>ROTFL!
L>Ну ткни что ли неуча в какой-нить FM, где, к примеру, сказано, как в студии моментально перепрыгнуть на парный открывающий/закрывающий символ? В виме — % (подозреваю, что для этого таки есть какая-то особенно извращенная распальцовка, да вот не нашел нигде)

Ctrl + ]

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Q>>Чушь какая-то. Девелопер МФС и девелопер .net работают в рамках одной платформы, единого подхода.
WH>MFC и .NET одна платформа...

Я плакал...

Не надо плакать, надо читать и думать — Windows платформа.

Q>>Для Unix требуются совершенно другие знания других библиотек и других подходов.
WH>Неа. Нужно умение разбираться в том что видишь первый раз.
WH>В прочем это умение нужно всегда и везде.
WH>Ибо по сравнению со спецификой конкретного проекта стандартные линуксовые библиотечки просто детский лепет.

Ну то-то и видно. Если не хватает желания научиться использовать стандартный редактор под Unix, то что же говорить тогда о знании sed, awk, ksh scripts, разных utilities и других страшных слов. Без этих инструментов под Unix жизнь сложна и неприятна.

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

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

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

Q>>Чушь какая-то. Девелопер МФС и девелопер .net работают в рамках одной платформы, единого подхода. Для Unix требуются совершенно другие знания других библиотек и других подходов.

A>Извини за глупый и бестактный вопрос: но ты под Unix писал когда-нибудь?
A>(Мне просто в свое время показалось изучить unix сильно проще чем MFC, которую я так до конца и не осилил вкурить)

Извини за глупый и бестактный вопрос: но ты под Unix писал когда-нибудь? Если да, то в чем смысл сравнения Unix и MFC? Может не будем сравнивать паровоз и карданный вал.

Если же по существу, то в Unix традиционно приветствуется подход имплементации сложных структур из простых блоков. Каждый из блоков достаточно легко изучить, в отличие от монолитной монстроидальной MFC.

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

Q>Извини за глупый и бестактный вопрос: но ты под Unix писал когда-нибудь? Если да, то в чем смысл сравнения Unix и MFC? Может не будем сравнивать паровоз и карданный вал.
В том что тут было высказано мнение что Linux это что-то особенное... меж тем изучение линукса ничем не отличатся от изучения MFC или какой либо иной библиотеки.
На сам посуди какая разница какое именно API учить? API библиотеки или API ОС?

Q>Если же по существу, то в Unix традиционно приветствуется подход имплементации сложных структур из простых блоков. Каждый из блоков достаточно легко изучить, в отличие от монолитной монстроидальной MFC.
А это уже в данной теме не существенные детали.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

C>>Что касается мыши — я ее вообще почти не трогаю в VS. Для чего она там нужна?
IS>переключаться между окнами.
ctrl-tab, для перехода в солюшн — ctrl-alt-l и т.д.

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

NBN>>Это если можно — тоже. Я правда не так много шаблонов файлов использую (90% заголовочники и 10% проектные файлы), но в впринципе не вижу проблем увеличить количество шаблонов до произвольного количества. Шаблоны через VA.

L>А так чтобы Add new class -> и у тебя сгенерированные файлы имеют заголовок, принятый в вашей конторе, guard macro вместо прагмы и т.п? Чтобы не ручками все это править?

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

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

L>Зато точно нет автодополнения имени файла на диске...

Если ты про #include "тра-та-та" то есть.

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

L>Речь изначально про linux шла, между прочим.

К сожалению я линуксом страдал только в розовом детстве... Ещё в те времена когда шаверму ел... Золотые годы

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

L>>>Попробуй, к примеру, сделать это в русской раскладке. Особенно с установленным ассистом. Результат удивит.
C>>А команды ViMа уже у нас тоже в русской раскладке работают?
L>Сюрприз?
Ага. Попробовал в ViM — пишет букву "Ж" вместо ":". Нет, я понимаю, что при желании можно переназначить клавиши в keymap'ах. Но и в Windows можно всяких PuntoSwitcher'ов наставить.

C>>Проверил с Assist'ом — что я должен был увидеть?
L>У меня меню Ассиста вылезает. Ку?
Странный у тебя Ассист.

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

"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.

L>Но, прошу прощения, системно программировать под линух, ничего, кроме студии не зная — это нонсенс.
Я вот в Студии пишу ядерные модули для Линукса и системный софт (компилирую через SSH, проект монтирую с помощью SMB). VAssist прекрасно понимает системные заголовки Linux'а и делает нормальный autocomplete.

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

Q>Каждый из блоков достаточно легко изучить, в отличие от монолитной монстроидальной MFC.
Оффтопик.
Между прочим MFC будет менее монолитной и монстроидальной чем тот же Qt. Но на Qt, почему-то, никто не наезжает.

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

C>"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.

Эээ, а Tools->Debuger, там тебе и breakpoints и step into, step over и т.д.,
по-моему это лет 5 как есть.

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

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

L>>Зато точно нет автодополнения имени файла на диске...

NBN>Если ты про #include "тра-та-та" то есть.

Добавляется ассистом, я как бы в курсе.

А кроме инклюдов?
Вот батничек там написать или еще чего...

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

C>>"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.
_>Эээ, а Tools->Debuger, там тебе и breakpoints и step into, step over и т.д.,
_>по-моему это лет 5 как есть.
Кааааакой, блин, Tools->Debugger в ViMе???? Там есть глючащий http://clewn.sourceforge.net/ , который еще и под Windows не работает.

Для EMacs'а есть аналогичные глюкоделки.

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

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

L>>Речь изначально про linux шла, между прочим.

NBN>К сожалению я линуксом страдал только в розовом детстве... Ещё в те времена когда шаверму ел... Золотые годы

Понятно, аргументы кончились

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

L>А кроме инклюдов?
L>Вот батничек там написать или еще чего...

Хм, я помню один случай за последний год когда писал батник... Зачем они сейчас нужны?

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

C>Проблема в том, что я уже очень долго ищу нормальную среду для разработки под Линукс. Так ничего нормального и не нашел.
C>"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.

Возможно я такой извращенец, но последнее время в процессе осваивания Emacs-а мне нравится им пользоваться все больше и больше. Как под Linux, так и под Windows.
Есть все что необходимо для комфортной работы.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Вот и отлично. У вас одни проблемы, у других — другие. Для вас знания linux не критичны, вы и в названии вакансии о linux небось не пишите. Но если другие об этом пишут значит именно это и надо.
Может хватит "прикладывать свой аршинчик" ко всему и ко всем?

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

KP>Возможно я такой извращенец, но последнее время в процессе осваивания Emacs-а мне нравится им пользоваться все больше и больше. Как под Linux, так и под Windows.
KP>Есть все что необходимо для комфортной работы.

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

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

DB>Вот и отлично. У вас одни проблемы, у других — другие. Для вас знания linux не критичны, вы и в названии вакансии о linux небось не пишите. Но если другие об этом пишут значит именно это и надо.
Если в вакансии написано линукс то это значит что разработка будет под линукс.
И больше ничего.
А разобраться с линухом не сложенне чем с любой другой библиотечкой. Особенно при наличии общих знаний.
Ибо с точки зрения изучения нет никакой разници между функциями библиоткеки и функциями ОС.
Это я тебе говорю как человек который пришол с винды и сходу начал писать линуховые кластерные решения.
Проблем было много и разных но ни одна из них не была связана с не знанием API линуха.

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

Q>>Каждый из блоков достаточно легко изучить, в отличие от монолитной монстроидальной MFC.
AJD>Оффтопик.
AJD>Между прочим MFC будет менее монолитной и монстроидальной чем тот же Qt. Но на Qt, почему-то, никто не наезжает.

Ты знаешь Qt по сравнению с MFC, это верх искусства дизайна. Монстроуозной ее никак не назовешь.

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

A>>(Мне просто в свое время показалось изучить unix сильно проще чем MFC, которую я так до конца и не осилил вкурить)

Q>Извини за глупый и бестактный вопрос: но ты под Unix писал когда-нибудь?
Да писал. Уже 2.5 года не пишу под винду. У меня даже на рабочей станции Linux стоит, притом что VS мне нравится до сих пор.
Твоя очередь отвечать на бестактный вопрос.

Q>Если да, то в чем смысл сравнения Unix и MFC? Может не будем сравнивать паровоз и карданный вал.
Это 2 технологии — требующие одинакового подхода в изучении. Просто одна из них чуть проще(unix)

Q>Если же по существу, то в Unix традиционно приветствуется подход имплементации сложных структур из простых блоков. Каждый из блоков достаточно легко изучить, в отличие от монолитной монстроидальной MFC.

Это к чему сказано? И как это подтверждает или опровергает тезисы выше по стеку?

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

A>Ты знаешь Qt по сравнению с MFC, это верх искусства дизайна. Монстроуозной ее никак не назовешь.

Ntv не менее принцип один и тот же

. Мегаклас_как_базовый + куча макросов на оброботчики. Хотя безусловно, дизайн Qt будет гораздо получше.

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

L>>>У меня меню Ассиста вылезает. Ку?
C>>Странный у тебя Ассист.
L>С официального сайта, между прочим.
Какой версии?

C>>Проблема в том, что я уже очень долго ищу нормальную среду для разработки под Линукс. Так ничего нормального и не нашел.
L>Под винду тоже из не густо, по большому счету.
C>>"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.
L>

L>Есть. Только зачем?
НЕТУ, нету нормальных. ViM и Emacs предоставляют "замечательную" интеграцию с командным окном GDB. Спасибо, блин, называется.

Тольк в ViM 7 появилась возможность ставить отметки брекпоинтов в gutter-зоне. Этим сейчас пользуется только один интегратор Clewn. А он жутко глючный, да еще и не работает в Windows.

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

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

C>>Я вот в Студии пишу ядерные модули для Линукса и системный софт (компилирую через SSH, проект монтирую с помощью SMB). VAssist прекрасно понимает системные заголовки Linux'а и делает нормальный autocomplete.
L>Интересно, господин хороший, а какой такой отладчик Вы умудрились интегрировать со студией, да так, что можете аж ядерные линуксовые модули отлаживать.. из-под винды-то?
Одно время использовал BVRDE — вообще замечательная IDE для удаленной компиляции. Сейчас испльзую, в основном, отладочную печать, что жутко меня бесит.

L>Я правильно понимаю, что у тебя такая схема — проект сидит на целиком на линух боксе, но исходники ты редактируешь по сети(!) с виндовой машины (!) через самбу (!),
Да.

L>а для компиляции у тебя открыт шелл (впрочем, это можно прикрутить к студии)?
Да, прикручено к студии — запускается через plink из Putty.

L>Ну и где тут "интеграция с отладчиком"? Ты используешь студию исключительно как редактор кода, причем далеко не самый лучший. Это даже не "стоя и в гамаке", это какой-то гораздо более экзотический случай.
Так в том-то и дело, что этот гамак оказывается быстрее рукопашной с ViM'ом.

L>You've made my night

Всегда рад помочь.

L>Хочешь совет? Два-пять дней, инвестированных в изучение родного для линукса редактора кода окупаются очень быстро. Шпаргалок в интернете полно, да и команд там не так много, зато экономия времени впоследствии просто ошеломительная.
ДВА-ПЯТЬ ДНЕЙ?? Ты смеешься?

Я месяц потратил на изучение Линуксовых инструментов. В ходе изучения отослал патчи в Code::Blocks, ECB, distcc и еще пару проектов, и пересмотрел с десяток IDE. В ViM я заныривал в исходники в поисках нужных мне фич (ну ПОЧЕМУ там нельзя сделать свой popup-диалог как для completion'а???), в Emacs — можешь посмотреть тему "XEmacs — помойка".

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

C>>Проблема в том, что я уже очень долго ищу нормальную среду для разработки под Линукс. Так ничего нормального и не нашел.
C>>"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.
KP>Возможно я такой извращенец, но последнее время в процессе осваивания Emacs-а мне нравится им пользоваться все больше и больше. Как под Linux, так и под Windows.
KP>Есть все что необходимо для комфортной работы.
Поработай c IDEA/Eclipse для Java — чтобы понять КАКОЙ должна быть настоящая IDE. Потом посмотри VAssist+MSVS в качестве бледного приближения к настоящей IDE. Потом посмотри на Emacs/ViM.

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

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

C>>>"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.
_>>Эээ, а Tools->Debuger, там тебе и breakpoints и step into, step over и т.д.,
_>>по-моему это лет 5 как есть.
C>Кааааакой, блин, Tools->Debugger в ViMе???? Там есть глючащий http://clewn.sourceforge.net/ , который еще и под Windows не работает.

Вообще-то имелся ввиду естественно emacs, у классического vim, стандартного меню.

C>Для EMacs'а есть аналогичные глюкоделки.

По крайней мере для взаимодействия с дебагером нету, т.к. есть работающее из коробки.

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

C>>Кааааакой, блин, Tools->Debugger в ViMе???? Там есть глючащий http://clewn.sourceforge.net/ , который еще и под Windows не работает.
_>Вообще-то имелся ввиду естественно emacs, у классического vim, стандартного меню.
А, ну так это не нормальная интеграция с отладчиком, а просто запуск консоли GDB.

C>>Для EMacs'а есть аналогичные глюкоделки.
_>По крайней мере для взаимодействия с дебагером нету, т.к. есть работающее из коробки.
Нетути. Есть http://www.inet.net.nz/~nickrob/ , который приближается уже к работающей версии. Но у меня он с С++ глючит.

УЁ>В корень не согласен с позицией. IDE позволяет не думать о порядке параметров и именах методов\переменных, не отвлекаться на добавление импортов, не искать в каком же там файле живет тот или иной класс\метод, не считать количество открывающихся и закрывающих скобок, не заниматься распознаванием образов в криво оформленном коде, а так же не делать много чего другого, что к программированию как таковому не относится, и сфокусироваться на решении проблемы. IDE это инструмент, и никаким образом не претендует на заменитель головы.

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

Я не против IDЕ, но если программер неможет собрать "Hello, world" с командной строки, то в линуксе ему делать нечего

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

УЁ>>В корень не согласен с позицией. IDE позволяет не думать о порядке параметров и именах методов\переменных, не отвлекаться на добавление импортов, не искать в каком же там файле живет тот или иной класс\метод, не считать количество открывающихся и закрывающих скобок, не заниматься распознаванием образов в криво оформленном коде, а так же не делать много чего другого, что к программированию как таковому не относится, и сфокусироваться на решении проблемы. IDE это инструмент, и никаким образом не претендует на заменитель головы.

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

Не стимулирование, а средство выживание. В проекте в котором я работаю, к коду приложило руку несколько десятков человек , из России, Штатов, Индии и даже Бразилии. Стоит ли говорить о качестве кода? А жить как то надо.

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

AZ>Я не против IDЕ, но если программер неможет собрать "Hello, world" с командной строки, то в линуксе ему делать нечего

С этим никто не спорит. Каждый программист должен начинать проект со скрипта автоматической сборки (не важно в какой OS), но это не означает что кто то в здравом уме будет (или должен уметь) работать без IDE.

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

AZ>Почти все упомянутое — стимулирование плохого стиля программирования.
Спорно. Сбрасывая некоторые организационные моменты на среду — ты освобождаешь время в том числе и на улучшение стиля программирования. Хотя по сути — как показывает опыт — стиль зависит ИСКЛЮЧИТЕЛЬНО от культуры программиста.

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

AZ>если я вынужден использовать тул который считает скобки — значит выражение переусложнено,
Вообще-то это нарушение ООП или стандарта кодирования. Это так же не относится к IDE.

AZ>криво оформленный код — проблема скорее организационная
Ну да, это лишнее пятно на карме программиста

AZ>Я не против IDЕ, но если программер неможет собрать "Hello, world" с командной строки, то в линуксе ему делать нечего
ИМХО, это тоже самое, что сказать — если программер неспособен набить на асме "Hello, world" то в программировании ему делать нечего

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

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

L>>А кроме инклюдов?
L>>Вот батничек там написать или еще чего...

NBN>Хм, я помню один случай за последний год когда писал батник... Зачем они сейчас нужны?
И правда, зачем нужны командные файлы/скрипты, когда всегда есть юзер?

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

NBN>>Хм, я помню один случай за последний год когда писал батник... Зачем они сейчас нужны?
L>И правда, зачем нужны командные файлы/скрипты, когда всегда есть юзер?

Ну вот я месяц назад настраивал автоматическую сборку проекта (инсталяхи под несколько платформ, 10 языков и прочие радости жизни). Единственный батник — отчищает папку, берёт всё из svn и запускает билд. Порядка 7 примитивных строк.

На время отладки — работают Build Events и иже с ними.

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

L>>С официального сайта, между прочим.
C>Какой версии?
Самой последней.
L>>Есть. Только зачем?
C>НЕТУ, нету нормальных. ViM и Emacs предоставляют "замечательную" интеграцию с командным окном GDB. Спасибо, блин, называется.
Не вижу проблемы. Или Вы без ГУЯ и шагу уже ступить не можете?

C>>>Я вот в Студии пишу ядерные модули для Линукса и системный софт (компилирую через SSH, проект монтирую с помощью SMB). VAssist прекрасно понимает системные заголовки Linux'а и делает нормальный autocomplete.
Вы, кстати, автокомплит в виме видели вообще?
L>>Интересно, господин хороший, а какой такой отладчик Вы умудрились интегрировать со студией, да так, что можете аж ядерные линуксовые модули отлаживать.. из-под винды-то?
C>Одно время использовал BVRDE — вообще замечательная IDE для удаленной компиляции. Сейчас испльзую, в основном, отладочную печать, что жутко меня бесит.

L>>Я правильно понимаю, что у тебя такая схема — проект сидит на целиком на линух боксе, но исходники ты редактируешь по сети(!) с виндовой машины (!) через самбу (!),
C>Да.
L>>Ну и где тут "интеграция с отладчиком"? Ты используешь студию исключительно как редактор кода, причем далеко не самый лучший. Это даже не "стоя и в гамаке", это какой-то гораздо более экзотический случай.
C>Так в том-то и дело, что этот гамак оказывается быстрее рукопашной с ViM'ом.
Отладчик-то где, я так и не понял? Меня убеждать не надо, какой редактор "быстрее", я всех устриц ел. Живих тоже, они, кстати, вкуснее.
L>>You've made my night

C>Всегда рад помочь.

L>>Хочешь совет? Два-пять дней, инвестированных в изучение родного для линукса редактора кода окупаются очень быстро. Шпаргалок в интернете полно, да и команд там не так много, зато экономия времени впоследствии просто ошеломительная.
C>ДВА-ПЯТЬ ДНЕЙ?? Ты смеешься?
А чего там изучать? гугль.ком — Шпаргалка по vim. Там две-три страницы наиболее используемых команд. Или это слишком сложно/долго для программиста? (Вспоминаются где-то подслушанные слова "нам некогда юнит тесты писать, кодить надо"

)
C>Я месяц потратил на изучение Линуксовых инструментов. В ходе изучения отослал патчи в Code::Blocks, ECB, distcc и еще пару проектов, и пересмотрел с десяток IDE. В ViM я заныривал в исходники в поисках нужных мне фич (ну ПОЧЕМУ там нельзя сделать свой popup-диалог как для completion'а???), в Emacs — можешь посмотреть тему "XEmacs — помойка".
Э, нет. Вы не Вим изучали, а пытались сделать из него студию. Почувствуйте разницу, как говорится.
Более того, если десяток команд редактора Вам за месяц ниасилить, то как, позвольте спросить, Вы умудряетесь ядерные модули писать?

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

C>Здравствуйте, kaa.python, Вы писали:

C>>>Проблема в том, что я уже очень долго ищу нормальную среду для разработки под Линукс. Так ничего нормального и не нашел.
C>>>"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.
KP>>Возможно я такой извращенец, но последнее время в процессе осваивания Emacs-а мне нравится им пользоваться все больше и больше. Как под Linux, так и под Windows.
KP>>Есть все что необходимо для комфортной работы.
C>Поработай c IDEA/Eclipse для Java — чтобы понять КАКОЙ должна быть настоящая IDE. Потом посмотри VAssist+MSVS в качестве бледного приближения к настоящей IDE. Потом посмотри на Emacs/ViM.
Какой эклипс посмотреть, если я программирую на C++?

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

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

L>Вообще, господа хорошие, хочу снова напомнить анекдот про устриц. Судя по вашим возгласам, Вим/Емакс Вы видели только со стороны.
Вообще, господа хорошие, хочу снова напомнить анекдот про устриц. Судя по вашим возгласам, Студию Вы видели только со стороны.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

IS>>Здравствуйте, Cyberax, Вы писали:
C>>>Что касается мыши — я ее вообще почти не трогаю в VS. Для чего она там нужна?
IS>>переключаться между окнами.

L>Ctrl + Tab ?
переключается только в приделах файлов самой студии, умело обходя Tool Windows. Чтобы переключиться на Tool Window (которые обычно не на основном мониторе) придется ткнуть мышой в название окна в Ctrl-Tab списке а потом снова ткнуть что бы через секунду ткнуть мышой в него уже на другом мониторе (а иначе как ?). Так что мыша это пока еще необходимое дополнение к клаве, во всяком случае в студии. (хотя я на ++ах давно не пишу — и джЫдайские навыки программированивая почти утратил)

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

L>>Хочешь совет? Два-пять дней, инвестированных в изучение родного для линукса редактора кода окупаются очень быстро. Шпаргалок в интернете полно, да и команд там не так много, зато экономия времени впоследствии просто ошеломительная.
C>ДВА-ПЯТЬ ДНЕЙ?? Ты смеешься?

C>Я месяц потратил на изучение Линуксовых инструментов. В ходе изучения отослал патчи в Code::Blocks, ECB, distcc и еще пару проектов, и пересмотрел с десяток IDE. В ViM я заныривал в исходники в поисках нужных мне фич (ну ПОЧЕМУ там нельзя сделать свой popup-диалог как для completion'а???), в Emacs — можешь посмотреть тему "XEmacs — помойка".

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>>Я месяц потратил на изучение Линуксовых инструментов. В ходе изучения отослал патчи в Code::Blocks, ECB, distcc и еще пару проектов, и пересмотрел с десяток IDE. В ViM я заныривал в исходники в поисках нужных мне фич (ну ПОЧЕМУ там нельзя сделать свой popup-диалог как для completion'а???), в Emacs — можешь посмотреть тему "XEmacs — помойка".
KP>мне кажется, стоит поработать над методиками изучения. работать с Emacs можно после 2-3 дней его изучения и расппечатывания шпаргалки.
Чем мне эти шпаргалки помогут, если у меня не работает нормально отладчик в нем? Хоткеи я и так прекрасно могу запомнить.

На Emacs я потратил больше двух недель работы.

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

C>Чем мне эти шпаргалки помогут, если у меня не работает нормально отладчик в нем? Хоткеи я и так прекрасно могу запомнить.

честно сказать, я и не пользовался его отладчиком

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>>>С официального сайта, между прочим.
C>>Какой версии?
L>Самой последней.
У меня примерно трехлетней давности.

C>>НЕТУ, нету нормальных. ViM и Emacs предоставляют "замечательную" интеграцию с командным окном GDB. Спасибо, блин, называется.
L>Не вижу проблемы. Или Вы без ГУЯ и шагу уже ступить не можете?
Могу. Сейчас вот отлаживаю систему через JTAG.

Только вот это неудобно. Все равно, что руками делать GET-запросы через telnet вместо использования браузера.

C>>>>Я вот в Студии пишу ядерные модули для Линукса и системный софт (компилирую через SSH, проект монтирую с помощью SMB). VAssist прекрасно понимает системные заголовки Linux'а и делает нормальный autocomplete.
L>Вы, кстати, автокомплит в виме видели вообще?
Я в его внутренности залезал. Обычно в ViMе для источника комплитпа используют ctags (я даже начинал прикручивать XRefactory). Ctags для исходников на С вполне адекватен (хотя и уступает VAssist'у), но вот для С++ даже близко не приближается к нормальному.

L>>>Ну и где тут "интеграция с отладчиком"? Ты используешь студию исключительно как редактор кода, причем далеко не самый лучший. Это даже не "стоя и в гамаке", это какой-то гораздо более экзотический случай.
C>>Так в том-то и дело, что этот гамак оказывается быстрее рукопашной с ViM'ом.
L>Отладчик-то где, я так и не понял? Меня убеждать не надо, какой редактор "быстрее", я всех устриц ел. Живих тоже, они, кстати, вкуснее.
Вот здесь отладчик: http://bvrde.sourceforge.net/

L>>>Хочешь совет? Два-пять дней, инвестированных в изучение родного для линукса редактора кода окупаются очень быстро. Шпаргалок в интернете полно, да и команд там не так много, зато экономия времени впоследствии просто ошеломительная.
C>>ДВА-ПЯТЬ ДНЕЙ?? Ты смеешься?
L>А чего там изучать? гугль.ком — Шпаргалка по vim. Там две-три страницы наиболее используемых команд. Или это слишком сложно/долго для программиста?
Да мне глубоко плевать на эти списки команд. Пару десятков хотекеев я прекрасно в помощи посмотрю и запомню, никакой проблемы нет. Для меня редактирование текста — это очень маленькая часть того, что должна делать система. И восторженные экстатические писки поклонников ViMа: "А у нас есть блоковое выделение!" или "А мы еще умеем регэкспами заменять!", — меня ничуть не трогают.

А дальше мы натыкаемся на стену. Где у нас HOWTO по использованию визуального отладчика в Emacs/ViM? Где у нас нормальный autocomplete? И т.п.

C>>Я месяц потратил на изучение Линуксовых инструментов. В ходе изучения отослал патчи в Code::Blocks, ECB, distcc и еще пару проектов, и пересмотрел с десяток IDE. В ViM я заныривал в исходники в поисках нужных мне фич (ну ПОЧЕМУ там нельзя сделать свой popup-диалог как для completion'а???), в Emacs — можешь посмотреть тему "XEmacs — помойка".
L>Э, нет. Вы не Вим изучали, а пытались сделать из него студию. Почувствуйте разницу, как говорится.
Так чувствую, каждый день. Всю убогость классических юниксовых решений...

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

C>>>Я месяц потратил на изучение Линуксовых инструментов. В ходе изучения отослал патчи в Code::Blocks, ECB, distcc и еще пару проектов, и пересмотрел с десяток IDE. В ViM я заныривал в исходники в поисках нужных мне фич (ну ПОЧЕМУ там нельзя сделать свой popup-диалог как для completion'а???), в Emacs — можешь посмотреть тему "XEmacs — помойка".
L>>Э, нет. Вы не Вим изучали, а пытались сделать из него студию. Почувствуйте разницу, как говорится.
C>Так чувствую, каждый день. Всю убогость классических юниксовых решений...
Гы, доча, лол.
И всю красоту и изящество уиндоузных, надо полагать?

S>ну эт вы батенька загнули, таких не берут. дебагать точно прийдётся на целевой платформе.
S>попробуй ещё NetBeans. но вобщем в любом случае VC лучьший.

По поводу NetBeans и Линукса. К нему еще что-то надо чтобы писать на С++.

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

L>>>Э, нет. Вы не Вим изучали, а пытались сделать из него студию. Почувствуйте разницу, как говорится.
C>>Так чувствую, каждый день. Всю убогость классических юниксовых решений...
L>Гы, доча, лол.
L>И всю красоту и изящество уиндоузных, надо полагать?
На убогость виндовых решений я тоже часто натыкаюсь, не волнуйся. Однако, некоторые программы в Винде просто не имеют аналогов в Linux'е.

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

C>>>Так чувствую, каждый день. Всю убогость классических юниксовых решений...
L>>Гы, доча, лол.
L>>И всю красоту и изящество уиндоузных, надо полагать?
C>На убогость виндовых решений я тоже часто натыкаюсь, не волнуйся. Однако, некоторые программы в Винде просто не имеют аналогов в Linux'е.
А причем тут это?

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

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

Да чего уж там мелочиться. "Оптимус Максимус" прикупил и впкрёд.

Правда, тогда отпадёт вся элитарность инструмента и, возможно, тут то он и станет никому не нужным.

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

Во-во, далеко не везде. За последние 7 лет программирования у меня необходимости добавить линковку библиотеки во все проекты разом ни разу не возникло. Обычно заодно код приходится написать, который будет эту библиотеку использовать. А его во все проекты разом все равно с помощью make не добавишь. Вернее, добавишь, но смысла в этом не будет.

Posted via RSDN NNTP Server 2.1 beta

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

L>Нет, ну право, весьма полезный флейм. Вот я про "Ctrl-[" узнал (справка от МС — гадость редкостная) и попутно таки нашел список дефолтных шорткатов в студии. Только вот у меня пальцы в большинстве случаев так не растопыриваюццо,
Плохому танцору...
L>да и как. к примеру,
Легко.
L>удалить весь текст с текущей позиции до конца строки
shift + end, del
L>(файла)
ctrl + shift + end, del
L>или скопировать 5-6 (100-200) строк текста одним махом, не нашел

home, home, shift + стрелочки или pg up/pg down и выделяешь сколько нужно.

L>Вот обратите внимание — я одинаково успешно работаю как в одной, так и в другой системе.
В студии ты работать не умеешь. Это давно понятно.
L>Я высказал список того, чего мне не хватает в студии и узнал, где регекспы и как искать парные символы.
Лично мне ни то ни другое никогда небыло нужно.
L>Правда, для меня редактор студии от этого сильно удобнее не стал по ряду причин, которые апологетам студии, до сих пор считающих, что vi/emacs — это такой Блокнот не от МС, понять будет сложно.
Может все же объяснишь?
А то ты так ничего и не назвал. Все что назвал есть в студии.
Все что ты продемонстрировал это не знание того как работать в студии.

L>Ау, неужели не интересно, как люди без этой интеграции живут, умудряясь создавать стабильные и надежные системы?
Пальци...

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

C>>Поработай c IDEA/Eclipse для Java — чтобы понять КАКОЙ должна быть настоящая IDE. Потом посмотри VAssist+MSVS в качестве бледного приближения к настоящей IDE. Потом посмотри на Emacs/ViM.
L>Какой эклипс посмотреть, если я программирую на C++?
Для общего развития посмотри. Чтобы потом не было вопросов про то, как должна выглядеть IDE.

Кстати, в Eclipse есть CDT для С++, но он весьма примитивный (хотя с отладичиком работает нормально).

L>Вообще, господа хорошие, хочу снова напомнить анекдот про устриц. Судя по вашим возгласам, Вим/Емакс Вы видели только со стороны.
Да, конечно. А вы Студию никогда вообще не видели.

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

L>>Ctrl + Tab ?
IS>переключается только в приделах файлов самой студии, умело обходя Tool Windows. Чтобы переключиться на Tool Window (которые обычно не на основном мониторе) придется ткнуть мышой в название окна в Ctrl-Tab списке а потом снова ткнуть что бы через секунду ткнуть мышой в него уже на другом мониторе (а иначе как ?). Так что мыша это пока еще необходимое дополнение к клаве, во всяком случае в студии. (хотя я на ++ах давно не пишу — и джЫдайские навыки программированивая почти утратил)

А ты давно студию в руках держал. В 2005-й никаких проблем переключиться на Tool Window по Ctrl + Tab нет.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

KP>и подобных примеров будет огромное множество.
Еще пожалуйста.

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

AJD>Какой-то странный пример. ИМО, гораздо более вероятно, что тебе прийдется добавлять линковку только к конкретному проекту(ам)

жизненный пример. из текущих проектов.

AJD>Еще пожалуйста.

выполнение внешних команд.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

KP>выполнение внешних команд.

А что с ними не так?

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

A>>Ты знаешь Qt по сравнению с MFC, это верх искусства дизайна. Монстроуозной ее никак не назовешь.
AJD>Ntv не менее принцип один и тот же

. Мегаклас_как_базовый + куча макросов на оброботчики. Хотя безусловно, дизайн Qt будет гораздо получше.

Извини, но в QT вышаются нормальные функции на обработку событий, а не здоровый switch-case в макросах. Плюс формы в Qt стянулы layout-ом и сами правильно растягиваются, а в MFC перетрахаться нужно, чтобы это написать, поэтому никто не делает.

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

A>Извини, но в QT вышаются нормальные функции на обработку событий, а не здоровый switch-case в макросах.

В Qt таким же образом цепляются функции макросами. Разница только кто это делает С++ препроцессор или препроцессор от Qt который может вывалится с бессмысленным сообщением типа "internal error"

A>Плюс формы в Qt стянулы layout-ом и сами правильно растягиваются, а в MFC перетрахаться нужно, чтобы это написать, поэтому никто не делает.
Это не имеет отношение к дизайну. Да функционала в Qt поболее будет.

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

A>>Плюс формы в Qt стянулы layout-ом и сами правильно растягиваются, а в MFC перетрахаться нужно, чтобы это написать, поэтому никто не делает.
AJD>Это не имеет отношение к дизайну. Да функционала в Qt поболее будет.

C другой стороны QT вроде довольно тормозявый.

Сорри что вмешиваюсь — а что за нужда постоянно натравливать регэкспы на код? Причём, насколько я понимаю, код C++-ный?

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

... << RSDN@Home 1.2.0 alpha rev. 676>>

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

C>>Проблема в том, что я уже очень долго ищу нормальную среду для разработки под Линукс. Так ничего нормального и не нашел.
C>>"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.
FR>http://www.slickedit.com/ не смотрел?
Смотрел. Как-то не особо понравился, хотя автокомплит для С++ там очень неплохой.

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

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

A>>>Ты знаешь Qt по сравнению с MFC, это верх искусства дизайна. Монстроуозной ее никак не назовешь.
AJD>>Ntv не менее принцип один и тот же

. Мегаклас_как_базовый + куча макросов на оброботчики. Хотя безусловно, дизайн Qt будет гораздо получше.

A>Извини, но в QT вышаются нормальные функции на обработку событий, а не здоровый switch-case в макросах. Плюс формы в Qt стянулы layout-ом и сами правильно растягиваются, а в MFC перетрахаться нужно, чтобы это написать, поэтому никто не делает.

Switch нужен если под WinAPI писать без MFC на макросах <windows.h>. В MFC switch внутри фреймворка. В юзеровском коде нужно добавить обработчик в message map, чтобы фреймворк вызывал этот обработчик.

И вообще MFC — это, в основном, всего лишь плюсовая обертка над WinAPI. Ее некорректно сравнивать с QT?

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

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

L>>Может, для начала следует научиться писать код так, чтобы не было необходимости в отладчике?
WH>Пальцан...
WH>Со стронней либой которая валит приложение в кору тоже без отладчика разбираться будешь?
вот это и было той самой "парой случаев".
Только тут интеграция редактора с отладчиком никак не поможет, знаете ли.

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

L>А ты давно студию в руках держал. В 2005-й никаких проблем переключиться на Tool Window по Ctrl + Tab нет.
Регулярно держу. А ты ?
Попробовал переключаться по C+T — мышой все равно гораздо быстрее получается.

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

L>>>удалить весь текст с текущей позиции до конца строки
WH>>shift + end, del
L>(vim)D
L>>>(файла)
WH>>ctrl + shift + end, del
L>(vim)dG
L>>>или скопировать 5-6 (100-200) строк текста одним махом, не нашел

WH>>home, home, shift + стрелочки или pg up/pg down и выделяешь сколько нужно.
L>считая в уме? Эргономично, ничего не скажешь.
L>(vim)100yy — скопировать 100 строк

L>Попробуйте Ваши шорткаты на клавиатуре ноутбука, кстати. Особенно когда умеете печатать вслепую.

А еще на КПК тоже не слишком удобно получается...

WH>>В студии ты работать не умеешь. Это давно понятно.
L>Правда, что ли? А Вы без студии вообще как без рук, похоже.
L>>>Я высказал список того, чего мне не хватает в студии и узнал, где регекспы и как искать парные символы.
WH>>Лично мне ни то ни другое никогда небыло нужно.
L>Может, пора признаться себе, что Вы просто гуевый мышевозила?

Это какой-то приговор?

L>>>Правда, для меня редактор студии от этого сильно удобнее не стал по ряду причин, которые апологетам студии, до сих пор считающих, что vi/emacs — это такой Блокнот не от МС, понять будет сложно.
WH>>Может все же объяснишь?
L>Очень трудно объяснить это человеку, который к аргументам глух как стенка.

Это точно.

WH>>А то ты так ничего и не назвал. Все что назвал есть в студии.
L>Приведенные выше шорткаты. Они есть, только использовать их банально неудобно.

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

Задача скопировать 100 строк несомненно интересна — а какое-нибудь практическое примение у нее есть?

WH>>Все что ты продемонстрировал это не знание того как работать в студии.
L>Заметь, это незнание того, как эффективно работать с редактором студии. Я это и не отрицаю хотя бы потому, что он нихрена не эргоноичный.

Да, кроме эффективной работы с редактором исходных вещей "студия" оснащена еще туевой хучей инструментов, однако же лично Вам...

L>>>Ау, неужели не интересно, как люди без этой интеграции живут, умудряясь создавать стабильные и надежные системы?
WH>>Пальци...
L>Пальцы это "дайте мне студию, и неважно что пишем под [unix|VxWorks|symbian...], бо без интеграции с отладчиком и жизнь не мила".

... ни интегрированный отладчик, ни прочие "излишества" совершенно не интересны — о чем спор?

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

V>landerhigh пишет:
>>
>> Может, для начала следует научиться писать код так, чтобы не было
>> необходимости в отладчике?
V>Не удержался, но наконец я увидел здесь гуру дао-программирования.
V>Преклоняю перед Вами колени.
Хинт: юнит-тесты.
V>З.Ы. Даже землю когда лепили и то патчи в виде диких зверей выпускали...
потому что покрытие кода юнит-тестами было неважное

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

WH>>shift + end, del
L>(vim)D
Ой лукавишь...
Воспроизвожу последовательность находясь в режиме редактирования:
Esc — Переход в коммандный режим. Зачем курсор сдвинуля на одну позицию влево?
стрелка в право
shift + d — Удаляем. Опять курсор уехал

i — Переход в режим редактирования
стрелка в право

В студии как и в большинстве других виндовых редакторов два нажатия.
Причем это две ортогональные операции. Выделение и удаление. Те их можно комбинировать с другими операциями.

L>(vim)dG
Таже байда.

L>считая в уме? Эргономично, ничего не скажешь.
L>(vim)100yy — скопировать 100 строк
Я не могу вспомнить ни одного случая когда мне нужно было скопировать N строк когда N я знал зарание.
Я всегда знаю что мне нужно скопировать от сюда до туда. Если текста много то использую page up/page down и потом подруливаю стрелочками.
А сколько там строк я никогда не задумываюсь. Мне что делать больше нечего чем строки считать?

L>Попробуйте Ваши шорткаты на клавиатуре ноутбука, кстати. Особенно когда умеете печатать вслепую.
Ты еще на телефоне писать предложи.

L>Может, пора признаться себе, что Вы просто гуевый мышевозила?

Что-то мне подсказывает что кластеры под линух я пишу как минимум не хуже чем ты.

L>Очень трудно объяснить это человеку, который к аргументам глух как стенка.
Во-во... ни одного аргумента... одни понты и голословные заявления...

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

L>Заметь, это незнание того, как эффективно работать с редактором студии. Я это и не отрицаю хотя бы потому, что он нихрена не эргоноичный.
По сравнению с вимом верх эргономики.

L>Пальцы это "дайте мне студию, и неважно что пишем под [unix|VxWorks|symbian...], бо без интеграции с отладчиком и жизнь не мила".
Без отладчика можно обойтись.
Но вот редактор в студии банально удобней.
И менять его на линуховые поделки в которых ради примитивного действия нужно плясать с бубном (см выше) я не намерен.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

L>Для любых шорткатов студии необходимо "переключение контекста", т.е. как максимум отрывать внимание, а как минимум — переносить руки.
Исключительно тем кто не умеет ими пользоваться.
Я провожу эти действия вобще не думая о них. И уж точно не трогаю мышу.

L>Опять же, не заточена она на использование клавиатуры только, приходится и мышой возить.
Это исключительно от незнания.
В мелкомяхких приложениях вобще и в студии тем болие вобще нет действий которые можно сделать только мышой (по крайней мере мне о таких не извесно).

L>Это синтетический пример. Более реальный — видишь три/пять строк кода и одним махом их копируешь/удалаяешь.
Я быстрее их стрелочками выделю чем буду считать сколько там строк.

L>Я, кстати, даже не заикнулся про повтор последней команды. В vim жмешь "." и получаешь повтор последней команды редактирования, как то регексп, копирование/удаление/вставка. Это очень сильная вещь, между прочим (не надо сравнивать с записью макросов, плиз).
Как по мне совершенно безполезная. В отличии от записи макросов.
Ибо повторить комманду я могу и шорткатом.
А когда нужно повторить несколько комманд... например нужно сделать switch/case по значениям некоторого enum'а.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

Q>Vi затачивался под удобство программистов еще когда Билл Гейтс окошки у Эппл воровал.

все-таки стоит признать — удобство вещь крайне субъективная. и когда ВСЕ редакторы ведут себя одним способом, а ОДИН другим это не совсем удобно и надо иметь крайне веские причины чтоб с этим одним разбираться. хотя, в определенных случаях время потраченное на разбирательство покроется сполна.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>>>или скопировать 5-6 (100-200) строк текста одним махом, не нашел

WH>>home, home, shift + стрелочки или pg up/pg down и выделяешь сколько нужно.
L>считая в уме? Эргономично, ничего не скажешь.
L>(vim)100yy — скопировать 100 строк

я долго читал этот бесполезный флейм, но вот это меня совсем поразило

А зачем может быть нужно скопировать ровно 100 строк (не 101, не 99), кроме как для создания большого массива нулей заданного размера? А зачем нужно делать эту функцию эргономичной? Вы каждые 5 минут копируете по 100 строк? А как вы их считаете, что это именно 100, а не 99? Может у вас это такая специфическая работа, копировать по 100 строк ?

L>Может, пора признаться себе, что Вы просто гуевый мышевозила?

от консольного батонодава слышу! %)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Q>Глупая придирка.
О пошли отмазки...

Q>Либо ты производишь удаление при просмотре текста, а значит уже в режиме команд и при этом все стандартные команды передвижения Vim ставят тебя на первый значащий символ, либо ты что-то писал, но вдруг тебе пришло в голову, что написал ты фигню и в этом случае отход на один символ назад наиболее логичен, поскольку можно сразу применить к последнему символу какую-нибудь команду.
Удаление это часть процесса редактирования. Не просмотра.
Я вобще фигею от логики: Либо можешь читать и удалять. Либо писать.
Где логика? Что курил автор?

Q>Ха-ха, знание Vim налицо. Все это делается командой C.
Вот скажи где логическая связь между D и C?
В студии есть две базовае операции. Выделить и удалить.
Я могу их комбинировать как мне нужно.
Все просто и интуитивно понятно. Для этого не нужны никакие доки.
А вот зная про D додуматься что C совмещает сразу 3 комманды в том числе D совершенно не реально.

Q>Учитывая, что такие удаления производятся при перемещении по тексту, а не редактировании, студия сосет по полной. Гораздо быстрее пройтись по строкам нажимая D, чем постоянно распальцовываться на s-e, del.
Если мне будет нужно у нескольких строк удалить хвост то я просто запишу макрос.
Или воспользуюсь прямоугольным выделением (shift + alt) иногда очень удобно. Особенно если код хорошо отформатирован.

Q>Что касается ортогональности, то в Vim она присутствует в гораздо большей мере. Команды типа d и c комбинируются с командами перемещения и позволяют указывать количество повторений перемещения и самих команд.
А в студии я могу писать макросы. Причем интерактивно, а не считая на сколько строк нужно сдвинуться.

Q>Да, способ выделения достойный. Стоит чихнуть не вовремя и выделяй все снова.
Ты постоянно чихаешь? Сочувствую.

Q>Вам бы в Петросяны.
Только после вас.

Q>Vi затачивался под удобство программистов еще когда Билл Гейтс окошки у Эппл воровал.
Только у Билла почемуто получилось лучше...

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

Q>В спорте есть такая вещь как техника. Все умеют кое-как бегать, прыгать и плавать, но только те, кто взял на себя труд изучить технику, делают все это по настоящему эффективно. Тоже самое верно для любых других областей человеческого знания.
О! Пошли доказательства по аналогии...
Куда идти с даказательствами по аналогии расказывать нужно?

... << RSDN@Home 1.2.0 alpha rev. 673>>

> AJD>Какой-то странный пример. ИМО, гораздо более вероятно, что тебе прийдется добавлять линковку только к конкретному проекту(ам)
>
> жизненный пример. из текущих проектов.

Тогда остается только посоветовать правильно организовывать не только мейкфайлы, но и проекты

В правильном солюшене не составит труда добавить новую библиотеку к файлу vsprops, общему для всех проектов.

Posted via RSDN NNTP Server 2.1 beta

kaa.python пишет:
>
>
> V>Хинт: не все, что тебе придеться писать можно покрыть юнит-тестами.
>
> можно поподробнее? покрыть Юнит-тестами, либо какой-то их вырожденной
> формой можно все.
Честно, мне лень подводить теоретическую базу с доказательствами. Долго
и не платят мне за это.
В частности вы можете запрограммировать такую минимальную
функциональность, для которой т.н. юнит-тест уже не будет оным и второе,
если все части системы работают, как предполагалось это не говорит, что
вся система будет работать тоже, как предполагалось.
Юнит-тесты — это всего-лишь один из инструментов написания программ в
соответствие с пожеланиями и никак не отвергают использование отладчика
и т.д.

Posted via RSDN NNTP Server 2.0

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

A>Я думаю такое мнение (что хорошее IDE плохо влияет на код) происходит оттого, что в хорошей оболочке проще работать, в итоге те люди, которым сложно или скучно осваивать командную строку, используют различные графические навороты. Естественно их код красотой не блещет. В итоге среди тех, кто использует различные графические оболочки большой процент плохих программистов.
A>Аналогично с бейсиком — язык слишком простой, не создаёт барьера использования. Как результат код пишут часто неопытные программисты.

ИМО, странная аналогия. Т.е. если в хорошем IDE есть мощные средства автоформатирования, рефакторинга (а в хорошем IDE они должны быть), то это приводит к плохому коду?

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

V>>Хинт: не все, что тебе придеться писать можно покрыть юнит-тестами.
KP>можно поподробнее? покрыть Юнит-тестами, либо какой-то их вырожденной формой можно все.
Драйверы (и ядерный код вообще), сложный код взаимодействия разных систем, код для встроеных систем. Ну и банальный GUI.

Часто стоимость test harness будет превышать стоимость всего проекта в разы.

Здравствуйте, landerhigh, Вы писали:
L>считая в уме? Эргономично, ничего не скажешь.
L>(vim)100yy — скопировать 100 строк
Рассмешил, спасибо.

L>Попробуйте Ваши шорткаты на клавиатуре ноутбука, кстати. Особенно когда умеете печатать вслепую.
Работаю на ноутбуке уже 2.5 года. Никаких проблем, даже еще удобнее — клавиши более компактно расположены. Кстати, ноутбук еще приучивает больше пользоваться клавиатурой, так как тачпад не так удобен, как мышка.

L>>>Я высказал список того, чего мне не хватает в студии и узнал, где регекспы и как искать парные символы.
WH>>Лично мне ни то ни другое никогда небыло нужно.
L>Может, пора признаться себе, что Вы просто гуевый мышевозила?

А может тебе стоит признать, что нифига ты не знаешь современные средства программирования?

L>>>Правда, для меня редактор студии от этого сильно удобнее не стал по ряду причин, которые апологетам студии, до сих пор считающих, что vi/emacs — это такой Блокнот не от МС, понять будет сложно.
WH>>Может все же объяснишь?
L>Очень трудно объяснить это человеку, который к аргументам глух как стенка.
Так чем Emacs отличается от продвинутого "Блокнота"? Они оба работают с текстом, разве что у Emacs'а больше средств работы с ним.

VisualStudio+VAssist работают уже с программой — они понимают структуру кода. Это уже совершенно другой уровень.

WH>>А то ты так ничего и не назвал. Все что назвал есть в студии.
L>Приведенные выше шорткаты. Они есть, только использовать их банально неудобно.
http://www.viemu.com/ — и наслаждайся своими шорткатами до посинения...

L>>>Ау, неужели не интересно, как люди без этой интеграции живут, умудряясь создавать стабильные и надежные системы?
WH>>Пальци...
L>Пальцы это "дайте мне студию, и неважно что пишем под [unix|VxWorks|symbian...], бо без интеграции с отладчиком и жизнь не мила".
Именно. Достает пользоваться уродскими инструментами.

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

M>кто без VS как без рук?
Не тим-лидом конечно.

Все равно все работает на одном и том-же железе, везде одинаковый код, одинаковые механизмы страничной адресации, одинаковый стандартный С++.
Я хочу сказать что грамотный человек имеет достаточную базу знаний основных принципов и стабильных неизменных от среды к среде механизмов.
В винде их склеили так, а в линухе немного иначе и что? Заполнить эти пробелы можно за относительно небольшое время.

Спроры про среду разработки считаю маразмом — среднеиндустриальные показатели числа строк кода на человека < 100 строк в день.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

R>Все равно все работает на одном и том-же железе, везде одинаковый код, одинаковые механизмы страничной адресации, одинаковый стандартный С++.
R>Я хочу сказать что грамотный человек имеет достаточную базу знаний основных принципов и стабильных неизменных от среды к среде механизмов.
R>В винде их склеили так, а в линухе немного иначе и что? Заполнить эти пробелы можно за относительно небольшое время.
R>Спроры про среду разработки считаю маразмом — среднеиндустриальные показатели числа строк кода на человека < 100 строк в день.
Фига. Эти <100 строк — из-за необходимости отлажитвать код, а не просто его писать. Хорошая IDE существенно это упрощает.

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

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

WH>Воспроизвожу последовательность находясь в режиме редактирования:
WH>Esc — Переход в коммандный режим. Зачем курсор сдвинуля на одну позицию влево?
Ээ.. ну, тебе уже ответили.
L>>(vim)100yy — скопировать 100 строк
WH>Я не могу вспомнить ни одного случая когда мне нужно было скопировать N строк когда N я знал зарание.
Легко. Две-три строки, даже считать ничего не надо.
WH>Я всегда знаю что мне нужно скопировать от сюда до туда. Если текста много то использую page up/page down и потом подруливаю стрелочками.
Подруливаю стрелокками? Классно сказано

WH>А сколько там строк я никогда не задумываюсь. Мне что делать больше нечего чем строки считать?
А если вдруг знаешь, сколько надо? Считать таки в уме?

L>>Попробуйте Ваши шорткаты на клавиатуре ноутбука, кстати. Особенно когда умеете печатать вслепую.
WH>Ты еще на телефоне писать предложи.
L>>Может, пора признаться себе, что Вы просто гуевый мышевозила?

WH>Что-то мне подсказывает что кластеры под линух я пишу как минимум не хуже чем ты.
Писать кластеры? В Студии?
L>>Очень трудно объяснить это человеку, который к аргументам глух как стенка.
WH>Во-во... ни одного аргумента... одни понты и голословные заявления...
Понты были от претендующих на синьора девелопера под Линух, ничего кроме Студии ниасиливших.
L>>Приведенные выше шорткаты. Они есть, только использовать их банально неудобно.
WH>Если ты не в состоянии их использовать, а у других это получается на уровне примитивной моторики то может с тобо что-то не то?
Эти команды невозможно повторить на уровне примитивной моторики. Ты вообще в курсе, где у разных нотебяков тот же Ins?
L>>Заметь, это незнание того, как эффективно работать с редактором студии. Я это и не отрицаю хотя бы потому, что он нихрена не эргоноичный.
WH>По сравнению с вимом верх эргономики.
...для гуевых мышевозил

L>>Пальцы это "дайте мне студию, и неважно что пишем под [unix|VxWorks|symbian...], бо без интеграции с отладчиком и жизнь не мила".
WH>Без отладчика можно обойтись.
WH>Но вот редактор в студии банально удобней.
Ну нету в студии редактора нормального. Например, те же completions работают только для кода, и то не всегда.
WH>И менять его на линуховые поделки в которых ради примитивного действия нужно плясать с бубном (см выше) я не намерен.
что-то Вас заносит, уважаемый. vi был придуман, когда Билли еще даже из универа не выгнали.
пример из той же оперы — TeX/LaTeX — ни одно коммерческое поделие до сих пор и рядом не стояло. Хотя да, виндузятники, ничего, кроме Уорда не видевшие, будут другого мнения.

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

Q>>Vi затачивался под удобство программистов еще когда Билл Гейтс окошки у Эппл воровал.
WH>Только у Билла почемуто получилось лучше...
Очень смелое утверждение

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

L>>>>Я высказал список того, чего мне не хватает в студии и узнал, где регекспы и как искать парные символы.
WH>>>Лично мне ни то ни другое никогда небыло нужно.
L>>Может, пора признаться себе, что Вы просто гуевый мышевозила?

C>А может тебе стоит признать, что нифига ты не знаешь современные средства программирования?
А что, для знания "современного программирования" необходимо уже пользоваться редактором, который кто-то считает современным?
L>>>>Правда, для меня редактор студии от этого сильно удобнее не стал по ряду причин, которые апологетам студии, до сих пор считающих, что vi/emacs — это такой Блокнот не от МС, понять будет сложно.
WH>>>Может все же объяснишь?
L>>Очень трудно объяснить это человеку, который к аргументам глух как стенка.
C>Так чем Emacs отличается от продвинутого "Блокнота"? Они оба работают с текстом, разве что у Emacs'а больше средств работы с ним.
Хотя бы тем, что блокнот — это такое наколенное поделие

C>VisualStudio+VAssist работают уже с программой — они понимают структуру кода. Это уже совершенно другой уровень.
Ага. Только completions в комментариях не работают (подумайте дважды, перед тем, как спрашивать зачем это надо, ладно?) Да и при программировании шаблонов толку от них маловато.
WH>>>А то ты так ничего и не назвал. Все что назвал есть в студии.
В том же vim completions работают всегда и везде.
L>>Приведенные выше шорткаты. Они есть, только использовать их банально неудобно.
C>http://www.viemu.com/ — и наслаждайся своими шорткатами до посинения...
Видел. Жалкая пародия.
L>>>>Ау, неужели не интересно, как люди без этой интеграции живут, умудряясь создавать стабильные и надежные системы?
WH>>>Пальци...
L>>Пальцы это "дайте мне студию, и неважно что пишем под [unix|VxWorks|symbian...], бо без интеграции с отладчиком и жизнь не мила".
C>Именно. Достает пользоваться уродскими инструментами.
Мыши плакали, кололись, но продолжали жрать кактус?

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

R>>Спроры про среду разработки считаю маразмом — среднеиндустриальные показатели числа строк кода на человека < 100 строк в день.
C>Фига. Эти <100 строк — из-за необходимости отлажитвать код, а не просто его писать. Хорошая IDE существенно это упрощает.
В течение последних двух месяцев у меня этот показатель доходил, бывало, и до -(минус)500 в днеь.
C>Собственно, после работы с GDB я понял, почему люди считают отладочную печать лучше, чем использование отладчика. Просто она действительно намного удобнее GDB.

Если только что написанный код надо отлаживать отладчиком, то таких "программистов" надо гнать в дворники ссаными тряпками.
То, что вы делаете в отладчике, легко автоматизируется юнит тестом, который затем включается в состав ночного билда и когда очередной Вася Пупкин организует в Вашем давно отлаженном коде очередной расстрел памяти, Вы, вместо того, чтобы с отладчиком наперевес трассировать всю систему (недельку-другую), просто выдадите люлей Васе.

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

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

AZ>>>Почти все упомянутое — стимулирование плохого стиля программирования.
NBN>>Спорно. Сбрасывая некоторые организационные моменты на среду — ты освобождаешь время в том числе и на улучшение стиля программирования. Хотя по сути — как показывает опыт — стиль зависит ИСКЛЮЧИТЕЛЬНО от культуры программиста.

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

Надо в байки занести — оно того стоит!

А какие такие "различные графические навороты" можно в коде использовать вообще?

A>Аналогично с бейсиком — язык слишком простой, не создаёт барьера использования. Как результат код пишут часто неопытные программисты.

Аналогия неверная — бейсика вы тоже не знаете...

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

L>>>Пальцы это "дайте мне студию, и неважно что пишем под [unix|VxWorks|symbian...], бо без интеграции с отладчиком и жизнь не мила".
WH>>Без отладчика можно обойтись.
WH>>Но вот редактор в студии банально удобней.
L>Ну нету в студии редактора нормального. Например, те же completions работают только для кода, и то не всегда.

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

К чему еще, кроме кода, вообще теоретически даже может работать completions?

WH>>И менять его на линуховые поделки в которых ради примитивного действия нужно плясать с бубном (см выше) я не намерен.
L>что-то Вас заносит, уважаемый. vi был придуман, когда Билли еще даже из универа не выгнали.
L>пример из той же оперы — TeX/LaTeX — ни одно коммерческое поделие до сих пор и рядом не стояло. Хотя да, виндузятники, ничего, кроме Уорда не видевшие, будут другого мнения.

"Уорда" Вы тоже не знаете...

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

WH>>>Но вот редактор в студии банально удобней.
L>>Ну нету в студии редактора нормального. Например, те же completions работают только для кода, и то не всегда.
TL>Народ, вы в своих аргументах бредить начинаете — а я на ваш бред к словам цепляться

К чему еще, кроме кода, вообще теоретически даже может работать completions?

Вот вы и попались, господин хороший.
Комментарии к коду, стало быть, совсем не пишем?
WH>>>И менять его на линуховые поделки в которых ради примитивного действия нужно плясать с бубном (см выше) я не намерен.
L>>что-то Вас заносит, уважаемый. vi был придуман, когда Билли еще даже из универа не выгнали.
L>>пример из той же оперы — TeX/LaTeX — ни одно коммерческое поделие до сих пор и рядом не стояло. Хотя да, виндузятники, ничего, кроме Уорда не видевшие, будут другого мнения.
TL>"Уорда" Вы тоже не знаете...

Ага... да и незачем.

Порисуйте в Уорде формулы, к примеру (это первое, что вспомнилось).

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

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

C>>VisualStudio+VAssist работают уже с программой — они понимают структуру кода. Это уже совершенно другой уровень.
L>Ага. Только completions в комментариях не работают (подумайте дважды, перед тем, как спрашивать зачем это надо, ладно?) Да и при программировании шаблонов толку от них маловато.

Ну если так — то конечно. Правда в комментариях и подсветки синтаксиса нет...

Лично я тупо пишу код, а потом нужное комментирую...

WH>>>>А то ты так ничего и не назвал. Все что назвал есть в студии.
L>В том же vim completions работают всегда и везде.

Это здорово.

L>>>Приведенные выше шорткаты. Они есть, только использовать их банально неудобно.
C>>http://www.viemu.com/ — и наслаждайся своими шорткатами до посинения...
L>Видел. Жалкая пародия.
L>>>>>Ау, неужели не интересно, как люди без этой интеграции живут, умудряясь создавать стабильные и надежные системы?
WH>>>>Пальци...
L>>>Пальцы это "дайте мне студию, и неважно что пишем под [unix|VxWorks|symbian...], бо без интеграции с отладчиком и жизнь не мила".
C>>Именно. Достает пользоваться уродскими инструментами.
L>Мыши плакали, кололись, но продолжали жрать кактус?

Именно!

Per aspera ad astra

"Иксоиды" — это все же реально "клан высших" — ну по крайней мере по их мнению. Правда не все "иксоиды" его придерживаются — встречаются и обычные люди, наплевательские относящиеся к "незнанию команд vim" каждым первым незнакомым или даже знакомым человеком.

А вот с первыми, с "несущими Слово Его" — общаться действительно трудно...

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

L>Здравствуйте, The Lex, Вы писали:

L>>>что-то Вас заносит, уважаемый. vi был придуман, когда Билли еще даже из универа не выгнали.
L>>>пример из той же оперы — TeX/LaTeX — ни одно коммерческое поделие до сих пор и рядом не стояло. Хотя да, виндузятники, ничего, кроме Уорда не видевшие, будут другого мнения.
TL>>"Уорда" Вы тоже не знаете...

L>Ага... да и незачем.

L>Порисуйте в Уорде формулы, к примеру (это первое, что вспомнилось).

И таки шо? В свое время рисовал очень активно — еще и за деньги — 3-4 работы за ночь — там этот ихний ActiveX еще и клавиатурой полнофункционально управляется — не говоря уже о том, что все импортится и биндится, скажем, из MathCAD — и даже, насколько я помню, из любимого математиками MathLab. В чем была фишка?

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

TL>>>"Уорда" Вы тоже не знаете...

L>>Ага... да и незачем.

L>>Порисуйте в Уорде формулы, к примеру (это первое, что вспомнилось).

TL>И таки шо? В свое время рисовал очень активно — еще и за деньги — 3-4 работы за ночь — там этот ихний ActiveX еще и клавиатурой полнофункционально управляется — не говоря уже о том, что все импортится и биндится, скажем, из MathCAD — и даже, насколько я помню, из любимого математиками MathLab. В чем была фишка?

Ну, насчет "полноценно управляется клавиатурой" это прогон.
Ради интереса, посмотрел бы, как это делает LaTeX и как выглядит результат его работы.

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

В данном сообщении аргументация полностью отсутствует.
Слив засчитан.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

WH>>Esc — Переход в коммандный режим. Зачем курсор сдвинуля на одну позицию влево?
L>Ээ.. ну, тебе уже ответили.
Ответили?
ИМХО в очередной раз слили.
Вот скажи как зная о наличии D понять что есть C? Именно понять. А не долго и нудно читать маны?
Да даже зная про C всеравно 3 действия против 2х в студии.

L>Легко. Две-три строки, даже считать ничего не надо.
2-3 строки я и так мнгновенно выделю.

WH>>Я всегда знаю что мне нужно скопировать от сюда до туда. Если текста много то использую page up/page down и потом подруливаю стрелочками.
L>Подруливаю стрелокками? Классно сказано

А что такого?
page up/page down как правило промахиватьюся не десяток другой строк.

L>А если вдруг знаешь, сколько надо? Считать таки в уме?

У меня ни разу такого небыло.
Те вобще никогда.

WH>>Что-то мне подсказывает что кластеры под линух я пишу как минимум не хуже чем ты.
L>Писать кластеры? В Студии?
Да. И они прекрасно работают, держат огромную нагрузку и линейно масштабируются.

WH>>Во-во... ни одного аргумента... одни понты и голословные заявления...
L>Понты были от претендующих на синьора девелопера под Линух, ничего кроме Студии ниасиливших.
А в чем понт то?

L>...для гуевых мышевозил

Гм... когда же я последний раз ГУИ то рисовал... ах да когда присал кроссплатформенный (win/web/хз что...) ГУИ движеок... чисто для отладки...

L>Ну нету в студии редактора нормального. Например, те же completions работают только для кода, и то не всегда.
То что ты им не умеешь пользоваться мы уже выиснили.

WH>>И менять его на линуховые поделки в которых ради примитивного действия нужно плясать с бубном (см выше) я не намерен.
L>что-то Вас заносит, уважаемый. vi был придуман, когда Билли еще даже из универа не выгнали.
Это не мешает vi быть поделкой.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

L>Если только что написанный код надо отлаживать отладчиком, то таких "программистов" надо гнать в дворники ссаными тряпками.
L>То, что вы делаете в отладчике, легко автоматизируется юнит тестом, который затем включается в состав ночного билда и когда очередной Вася Пупкин организует в Вашем давно отлаженном коде очередной расстрел памяти, Вы, вместо того, чтобы с отладчиком наперевес трассировать всю систему (недельку-другую), просто выдадите люлей Васе.

Вы какого типа и масштаба проекты делаете?

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

L>Ага. Только completions в комментариях не работают (подумайте дважды, перед тем, как спрашивать зачем это надо, ладно?)

А серьезно, зачем?

Если для документирования, а-ля doxygen, то это все шоткатами генерится, включая имя и параметры. А еще зачем?

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

L>Здравствуйте, The Lex, Вы писали:

TL>>>>"Уорда" Вы тоже не знаете...

L>>>Ага... да и незачем.

L>>>Порисуйте в Уорде формулы, к примеру (это первое, что вспомнилось).

TL>>И таки шо? В свое время рисовал очень активно — еще и за деньги — 3-4 работы за ночь — там этот ихний ActiveX еще и клавиатурой полнофункционально управляется — не говоря уже о том, что все импортится и биндится, скажем, из MathCAD — и даже, насколько я помню, из любимого математиками MathLab. В чем была фишка?

L>Ну, насчет "полноценно управляется клавиатурой" это прогон.
L>Ради интереса, посмотрел бы, как это делает LaTeX и как выглядит результат его работы.

Я смотрел — не ради интереса. А Вы смотрели как это делает Word?

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

C>>>>VisualStudio+VAssist работают уже с программой — они понимают структуру кода. Это уже совершенно другой уровень.
L>>>Ага. Только completions в комментариях не работают (подумайте дважды, перед тем, как спрашивать зачем это надо, ладно?) Да и при программировании шаблонов толку от них маловато.

TL>>Ну если так — то конечно. Правда в комментариях и подсветки синтаксиса нет...

Лично я тупо пишу код, а потом нужное комментирую...

L>А позвольте спросить, когда происходит это "потом" и как определяется, что есть "нужное"?

Ну как же? Я внимательно смотрю на разноцветные гуйовые символы на белом фоне и жду прихода, после чего бью в бубен и выдыхаю "Ахххм!" — и тут же вожу мышкой по, а она уже, пользуясь всеми новейшими наработками мелкософта, комментирует "нужное". Именно так и только так и происходит программирование в среде "неиксоидов"!

TL>>"Иксоиды" — это все же реально "клан высших" — ну по крайней мере по их мнению. Правда не все "иксоиды" его придерживаются — встречаются и обычные люди, наплевательские относящиеся к "незнанию команд vim" каждым первым незнакомым или даже знакомым человеком.

TL>>А вот с первыми, с "несущими Слово Его" — общаться действительно трудно...

L>О, да, в общении с отдельными индивидууами иногда думаешь, что им сам Билли платит за проповеди

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

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

C>>Собственно, после работы с GDB я понял, почему люди считают отладочную печать лучше, чем использование отладчика. Просто она действительно намного удобнее GDB.
L>Если только что написанный код надо отлаживать отладчиком, то таких "программистов" надо гнать в дворники ссаными тряпками.
Видимо, ты не работал с большими проектами. У меня очень часто при изменении твоего кода ломается какая-то другая библиотека.

L>То, что вы делаете в отладчике, легко автоматизируется юнит тестом, который затем включается в состав ночного билда и когда очередной Вася Пупкин организует в Вашем давно отлаженном коде очередной расстрел памяти, Вы, вместо того, чтобы с отладчиком наперевес трассировать всю систему (недельку-другую), просто выдадите люлей Васе.
Юнит-тест позволяет диагностировать регрессии. С ними проблем нет, проблемы с новыми ошибками.

Например, у меня в проекте есть бибилиотека, которая занимается созданием прозрачного распределенного графа объектов, автоматически синхронизируемого с базой. Код почти на 100% покрыт юнит-тестами. Тем не менее, именно с этой библиотекой у меня всегда больше всего проблем — очень часто натыкаюсь на непредусмотреный в библиотеке частный случай. При этом приходится долго отлаживать код и следить почему именно структура объектов не так как надо получается. При этом, нужно одновременно отлаживать клиентскую и серверную части.

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

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

TL>

Надо в байки занести — оно того стоит!

TL>А какие такие "различные графические навороты" можно в коде использовать вообще?

Например подсветка не только ключевых слов, но и имён пользовательских типов.

A>>Аналогично с бейсиком — язык слишком простой, не создаёт барьера использования. Как результат код пишут часто неопытные программисты.

TL>

Аналогия неверная — бейсика вы тоже не знаете...

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

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

A>Я не отношу себя к знатокам бейсика, никогда его не учил, но разбираться в коде приходилось. Каких-то особых сложностей не возникло.
А ты на нем что-нидь серьезное попиши — тогда и посмотрим, какой знаток. Уверяю, это будет сложнее, чем на С++ на порядок.
А так — я в этом случае тогда знаток Forth, PHP, Perl, Fortran, ABAP/4 да и вообще практически всех недекларативных языков (некоторые из этих языков я кстати учил, а не только разбираться приходилось). Давайте мне зарплату 10000 баксов как суперуниверсалу, жду вал предложений

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

A>>Я не отношу себя к знатокам бейсика, никогда его не учил, но разбираться в коде приходилось. Каких-то особых сложностей не возникло.
E>А ты на нем что-нидь серьезное попиши — тогда и посмотрим, какой знаток. Уверяю, это будет сложнее, чем на С++ на порядок.

Не понял — бейсик сложнее С++ что ли? Если писать большой проект, то понятно, что тяжело в любом случае будет. Но если надо быстро написать небольшую программу, то С++ использовать будет сложно, т.к. надо много времени на обучение. Бейсик, C# для этой цели лучше подойдут.

landerhigh wrote:
> TL>Народ, вы в своих аргументах бредить начинаете — а я на ваш бред к
> словам цепляться К чему еще, кроме кода, вообще теоретически даже может
> работать completions?
> Вот вы и попались, господин хороший.
> Комментарии к коду, стало быть, совсем не пишем?
А что не так с комментариями? Если мне нужно написать комментарий на
метод — я ставлю /** и моя IDE сразу мне подставит темплейт для него, с
заполнеными именами параметров.

Posted via RSDN NNTP Server 2.1 beta

landerhigh wrote:
> C>Драйверы (и ядерный код вообще), сложный код взаимодействия разных
> систем, код для встроеных систем. Ну и банальный GUI.
> Довольно значимую часть драйвера можно покрыть юнит-тестами, кстати.
Обычно очень сложно. Часто нужно для этого делать эмуляцию устройств, а
это само по себе уже очень сложно.

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

> C>Часто стоимость test harness будет превышать стоимость всего проекта в
> разы.
> , елси Вы не умеете их готовить.
Ну просветите меня, бедного...

> Правильный подход к юнит-тестированию понижает стоимость дальшейшей
> поддержки на порядки и даже сокращает время разработки.
Да-да-да. Это я все слышал. И даже иногда это работает — с
отдельными библиотеками, например.

Posted via RSDN NNTP Server 2.1 beta

landerhigh wrote:
> L>>Может, пора признаться себе, что Вы просто гуевый мышевозила?
> C>А может тебе стоит признать, что нифига ты не знаешь современные
> средства программирования?
> А что, для знания "современного программирования" необходимо уже
> пользоваться редактором, который кто-то считает современным?
Нет. Но причем здесь это? Мы же вроде занимаемся взаимными оскорблениями?

> C>Так чем Emacs отличается от продвинутого "Блокнота"? Они оба работают
> с текстом, разве что у Emacs'а больше средств работы с ним.
> Хотя бы тем, что блокнот — это такое наколенное поделие
И что? Чем принципиально отличается Emacs/vi и блокнот?

> C>VisualStudio+VAssist работают уже с *программой* — они понимают
> структуру кода. Это уже совершенно другой уровень.
> Ага. Только completions в комментариях не работают (подумайте дважды,
> перед тем, как спрашивать зачем это надо, ладно?)
В комментариях работает completion по словам. В _ХОРОШИХ_ IDE в
комментариях работает completion для кода. В ОЧЕНЬ ХОРОШИХ IDE в
комментариях и строковых литералах работает autocomplete даже для
injected languages.

> Да и при программировании шаблонов толку от них маловато.
Вполне нормально работает.

> WH>>>А то ты так ничего и не назвал. Все что назвал есть в студии.
> В том же vim completions работают всегда и везде.
Так как они тупы как пробка. Это просто доплнения по словам.

> L>>Приведенные выше шорткаты. Они есть, только использовать их банально
> неудобно.
> C>http://www.viemu.com/ — и наслаждайся своими шорткатами до посинения...
> Видел. Жалкая пародия.
Тебе нужны шорткаты из ViMа для вырезания 100 строк? Они там есть.

> L>>Пальцы это "дайте мне студию, и неважно что пишем под
> [unix|VxWorks|symbian...], бо без интеграции с отладчиком и жизнь не мила".
> C>Именно. Достает пользоваться уродскими инструментами.
> Мыши плакали, кололись, но продолжали жрать кактус?
Так а что делать? Нету нормального инструментария...

Posted via RSDN NNTP Server 2.1 beta

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

A>Не понял — бейсик сложнее С++ что ли? Если писать большой проект, то понятно, что тяжело в любом случае будет. Но если надо быстро написать небольшую программу, то С++ использовать будет сложно, т.к. надо много времени на обучение. Бейсик, C# для этой цели лучше подойдут.
Виноват, вообще запостил зря. Я слово НЕ не заметил, подумал, что кто-то считает себя знатоком на основании того, что когда-то разбирался

.
Естественно согласен. Но на бейсиках всяких писать я бы не сказал что проще, чем на С++. Вьезжаешь в язык быстрее — да, но из-за многих ограничений придется изголяться, вдобавок IDE оставляет желать лучшего. Ошибиться очень просто, и многие ошибки компилятор не заметит, проблемы будут только во время выполнения, и синтаксис ужасный, и обработка ошибок мягко говоря не очень. Вызывать какую-то API функцию с параметрами структура — танцы с бубном. Для простейших случаев все хорошо, как что посерьезнее надо — начинается большой геморой, ИМХО на плюсах их было бы меньше.
А VB.Net я вообще за бейсик уже не считаю, уже нормальный язык по возможностям.

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

E> Но на бейсиках всяких писать я бы не сказал что проще, чем на С++. Вьезжаешь в язык быстрее — да, но из-за многих ограничений придется изголяться

Как обычно происходит увлечение программированием (может и ошибаюсь, исследований здесь не проводил) — человек захотел что-то такое сделать (программу написать, узнал, что технология xxx — это круто, услышал, что заработать много можно), после этого тратит некоторое время на обучение. При этом не все доводят своё желание до конца. Многие отказываются по разным причинам (скучно, нет времени или мозгов, передумал). Чем сложнее язык тем больше надо потратить времени и больше иметь мозгов. В итоге отсеиваются не сильно умные люди, кроме того, если человек потратил на изучение языка программирования много времени, то наверное он и программок обучающих написал больше, больше узнал вообще о программировании, организации ЭВМ.
Т.е. в итоге средний С++-программист в среднем более квалифицирован, чем программист бейсик. Но это не значит, что надо учить С++ в ущерб бейсику (с-шарпу, функциональным языкам). Если человек приложит достаточные усилия для своего профессионального роста, то он будет хорошим специалистом, даже. если знает только бейсик. Но многие программисты будут кривиться от этого опыта, т.к. часто наблюдали плохо подготовленных коллег, которые используют бейсик.
В общем как-то много получилось, надеюсь выразил свою мысль.
Первоначально мысль была "хорошее IDE мозгам не помеха".

E>синтаксис ужасный

Синтаксис бейсика не нравится очень многим, кто долго с С или С++ работал. Просто привычка.

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

A>Как обычно происходит увлечение программированием (может и ошибаюсь, исследований здесь не проводил) — человек захотел что-то такое сделать (программу написать, узнал, что технология xxx — это круто, услышал, что заработать много можно), после этого тратит некоторое время на обучение. При этом не все доводят своё желание до конца. Многие отказываются по разным причинам (скучно, нет времени или мозгов, передумал). Чем сложнее язык тем больше надо потратить времени и больше иметь мозгов. В итоге отсеиваются не сильно умные люди, кроме того, если человек потратил на изучение языка программирования много времени, то наверное он и программок обучающих написал больше, больше узнал вообще о программировании, организации ЭВМ.
A>Т.е. в итоге средний С++-программист в среднем более квалифицирован, чем программист бейсик. Но это не значит, что надо учить С++ в ущерб бейсику (с-шарпу, функциональным языкам). Если человек приложит достаточные усилия для своего профессионального роста, то он будет хорошим специалистом, даже. если знает только бейсик. Но многие программисты будут кривиться от этого опыта, т.к. часто наблюдали плохо подготовленных коллег, которые используют бейсик.
A>В общем как-то много получилось, надеюсь выразил свою мысль.
A>Первоначально мысль была "хорошее IDE мозгам не помеха".

Есть такое хорошее понятие: overqualification — оной, уж простите, болезнью, страдают многие "истинные программисты". Лично я считаю профессионалом человека, реализующего решение задачи (с уточнениями и дополнениями). Не все решения — даже далеко не все — есть смысл решать на C++ и прочем ООП — для многих это действительно "колоть орехи микроскопом". За свою скромную карьеру я наблюдал подозрительно и даже неприятно большое количество действительно хорошо подготовленных коллег, прекрасно разбирающихся и в C++, и во всяких хитрых технологиях — которые, очевидно, очень тяготились своим знанием, поскольку очень часто (постоянно?

всегда?

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

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

E>>синтаксис ужасный

A>Синтаксис бейсика не нравится очень многим, кто долго с С или С++ работал. Просто привычка.

У LISP простой и я бы даже сказал гениальный синтаксис — много кому он действительно нравится?

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

C>landerhigh wrote:
>> C>Драйверы (и ядерный код вообще), сложный код взаимодействия разных
>> систем, код для встроеных систем. Ну и банальный GUI.
>> Довольно значимую часть драйвера можно покрыть юнит-тестами, кстати.
C>Обычно очень сложно. Часто нужно для этого делать эмуляцию устройств, а
C>это само по себе уже очень сложно.
Это не "обычно" сложно. Это очень просто. Гораздо проще, чем ловить потом BSODы и заниматься отписками с производителями железа.
>> С гуем будут сложности, да. Но это лишь еще один довод в пользу
>> разделения юзер интерфейса и логики.
C>Как ни разделяй — а интерфейс для сложных систем обычно все равно
C>остается сложным.
Чем сложнее система, тем заметнее выгода от отделения бизнес-логики и интерфейса.
>> C>Часто стоимость test harness будет превышать стоимость всего проекта в
>> разы.
>> , елси Вы не умеете их готовить.
C>Ну просветите меня, бедного...
про TDD что-нибудь слышали?
Еще раз — когда тесты являются неотъемлимой частью разработки и не воспринимаются программистами как некая (еще одна) непонятная обязаловка, спущенная сверху по прихоти менеджера или заказчика, их использование оказывает неоценимую помощь. Правильный подход помогает писать более компактный и стабильный код, выявляя потенциальные проблемы еще до того, как этот код увидит кто-то другой.
>> Правильный подход к юнит-тестированию понижает стоимость дальшейшей
>> поддержки на порядки и даже сокращает время разработки.
C>Да-да-да. Это я все слышал. И даже иногда это работает — с
C>отдельными библиотеками, например.
Будете в Сиднее, покажу одну такую "библиотеку"... хотя к тому времени, уже и не одну.

Интересно отметить, что Ваше непонимание того, в чем реальная польза UT, растет в определенном смысле из "интергрированного отладчика". А что, действительно велик соблазн по-быстрому набросать код, расставить брякпоинты, пройтись по коду с парой входных значений и посмотреть, получили ли то, что хотели. Только вот Вы забываете, что компьютер — это такая машина для автоматизации рутины. Юнит-тесты помогают автоматизировать то, что Вы привыкли делать руками в "интегрированном отладчике", причем несмотря на необходимость писать дополнительный код теста, размер которого порой на порядок превышает тестируемый код, экономия времени и прочих ресурсов вроде нервов в итоге окзаывается колоссальной.

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

L>>Ради интереса, посмотрел бы, как это делает LaTeX и как выглядит результат его работы.

TL>Я смотрел — не ради интереса. А Вы смотрели как это делает Word?

Ректально он это делает.
Что интересно, результат выглядит соответствующе.

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

L>>...для гуевых мышевозил

WH>Гм... когда же я последний раз ГУИ то рисовал... ах да когда присал кроссплатформенный (win/web/хз что...) ГУИ движеок... чисто для отладки...
L>>Ну нету в студии редактора нормального. Например, те же completions работают только для кода, и то не всегда.
WH>То что ты им не умеешь пользоваться мы уже выиснили.
Ну научи, дорогой, как включить автодополнение кода, работающее внутри блока комментария.

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

>> Комментарии к коду, стало быть, совсем не пишем?
C>А что не так с комментариями? Если мне нужно написать комментарий на
C>метод — я ставлю /** и моя IDE сразу мне подставит темплейт для него, с
C>заполнеными именами параметров.
Doxygen теги типа \code.. \endcode
господину специалисту по IDE что-нибудь говорят?

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

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

L>>Ага. Только completions в комментариях не работают (подумайте дважды, перед тем, как спрашивать зачем это надо, ладно?)

AJD>А серьезно, зачем?

AJD>Если для документирования, а-ля doxygen, то это все шоткатами генерится, включая имя и параметры. А еще зачем?
Банально в блоке \code..\endcode написать пример использования.

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

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

C>>>Собственно, после работы с GDB я понял, почему люди считают отладочную печать лучше, чем использование отладчика. Просто она действительно намного удобнее GDB.
L>>Если только что написанный код надо отлаживать отладчиком, то таких "программистов" надо гнать в дворники ссаными тряпками.
C>Видимо, ты не работал с большими проектами. У меня очень часто при изменении твоего кода ломается какая-то другая библиотека.
Индикатор никудышнего тестирования кода.
L>>То, что вы делаете в отладчике, легко автоматизируется юнит тестом, который затем включается в состав ночного билда и когда очередной Вася Пупкин организует в Вашем давно отлаженном коде очередной расстрел памяти, Вы, вместо того, чтобы с отладчиком наперевес трассировать всю систему (недельку-другую), просто выдадите люлей Васе.
C>Юнит-тест позволяет диагностировать регрессии. С ними проблем нет, проблемы с новыми ошибками.
Индикатор никудышнего тестирования кода.
C>Например, у меня в проекте есть бибилиотека, которая занимается созданием прозрачного распределенного графа объектов, автоматически синхронизируемого с базой. Код почти на 100% покрыт юнит-тестами. Тем не менее, именно с этой библиотекой у меня всегда больше всего проблем — очень часто натыкаюсь на непредусмотреный в библиотеке частный случай. При этом приходится долго отлаживать код и следить почему именно структура объектов не так как надо получается. При этом, нужно одновременно отлаживать клиентскую и серверную части.
Попробуйте изменить подход к "покрытию юнит-тестами".
C>После того, как ошибка найдена — для нее пишется юнит-тест, но саму ошибку-то надо сначала найти. Отладочная печать для этого жутко неудобна — приходится перекомпилировать и перезапускать приложение, если нужно добавить новую точку наблюдения.
Бывает. Еще можно лог к программе приделать.

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

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

L>>Если только что написанный код надо отлаживать отладчиком, то таких "программистов" надо гнать в дворники ссаными тряпками.
L>>То, что вы делаете в отладчике, легко автоматизируется юнит тестом, который затем включается в состав ночного билда и когда очередной Вася Пупкин организует в Вашем давно отлаженном коде очередной расстрел памяти, Вы, вместо того, чтобы с отладчиком наперевес трассировать всю систему (недельку-другую), просто выдадите люлей Васе.

_O_>Вы какого типа и масштаба проекты делаете?

Большие и распределенные
здесь, верхние два, you'll get an idea.
Последней нашей системы там пока нет почему-то, но она целиком и полностью test-driven.

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

L>Ну научи, дорогой, как включить автодополнение кода, работающее внутри блока комментария.
Какой процент времени у тебя уходит на то чтобы набить код в комментариях? Что-то мне подстказывает что 0.1% максимум.
Какого еще сфероконя типа кода в комментариях и копирования ровно 100 строк выдумаешь?

Кстати кстати ты так и не ответил где логическая связь между D и C?

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

L>Большие и распределенные
L>здесь, верхние два, you'll get an idea.
L>Последней нашей системы там пока нет почему-то, но она целиком и полностью test-driven.

Повезло, если ваш тип проектов можно полностью покрыть unit-test-ами. Но это ведь не везде так. Я средства моделирования делаю, здесь и front-end сложен и back-end и интеграция одного с другим. Плюс еще многообразные интеграции со сторонними продуктами. В общем, без дебаггера все равно не обойтись.

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

L>Кто бы меня научил писАть кросплатформенный код для Symbian... Расцеловал бы...

я писал. в чем проблема? логика работала на Symbian, Brew, WinCE, Win32. Тестировалась на Win32.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>>Кто бы меня научил писАть кросплатформенный код для Symbian... Расцеловал бы...
KP>я писал. в чем проблема? логика работала на Symbian, Brew, WinCE, Win32. Тестировалась на Win32.
На нативном Symbian'е? "Не верю" (с) Станиславский.

С Symbian'ом ничего больше не совместимо из-за их самопального механизма LEAVE'ов.

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

C>>> код для встроеных систем.
KP>>тоже никаких проблем. логика с легкостью делается кросс-платформенной и тестируется на Win или Linux.

L>Кто бы меня научил писАть кросплатформенный код для Symbian... Расцеловал бы...

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

И мощный враппер для системных функций и библиотеки С. Фигня

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

L>>>Кто бы меня научил писАть кросплатформенный код для Symbian... Расцеловал бы...
KP>>я писал. в чем проблема? логика работала на Symbian, Brew, WinCE, Win32. Тестировалась на Win32.
C>На нативном Symbian'е? "Не верю" (с) Станиславский.

C>С Symbian'ом ничего больше не совместимо из-за их самопального механизма LEAVE'ов.

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

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

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

C>На нативном Symbian'е? "Не верю" (с) Станиславский.

C>С Symbian'ом ничего больше не совместимо из-за их самопального механизма LEAVE'ов.

еще раз повторяю — МОЖНО.
само собой это несет некоторые ограничения. но код выходит кросс-платформенный. основное было отказаться от диких симбайновских пойнтеров в пользу void*, но именно к void* пришли из за Brew.
а вообще логика была достаточно сложная (взаимодействие Филиповским Speech Recognition Server) и отображение полученных данных. Отлаживать подобное на Symbian было очень и очень накладно. Само собой для всех платформ был платформозависимый код. Главное грамотно разделить на компоненты.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

KP>еще раз повторяю — МОЖНО.
KP>само собой это несет некоторые ограничения. но код выходит кросс-платформенный. основное было отказаться от диких симбайновских пойнтеров в пользу void*, но именно к void* пришли из за Brew.

Ты о чём? DesC?
А почему именно void*, что мешало обычные указатели использовать?

NBN>Пишешь код, придерживаясь своей или их системы исключений

И мощный враппер для системных функций и библиотеки С. Фигня

Продай талант... Тьфу, не талант — враппер!

... << RSDN@Home 1.2.0 alpha rev. 676>>

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

NBN>>Пишешь код, придерживаясь своей или их системы исключений

И мощный враппер для системных функций и библиотеки С. Фигня

L>Продай талант... Тьфу, не талант — враппер!
L>)

Враппер для функций — NDA от LG

NBN>Враппер для функций — NDA от LG

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

Пойду убьюсь об стену

... << RSDN@Home 1.2.0 alpha rev. 676>>

NBN>Я тоже писал, под ту же портянку платформ. Ничего не мешает тебе так же использовать самописные ливы

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

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

... << RSDN@Home 1.2.0 alpha rev. 676>>

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

NBN>Ты о чём? DesC?
NBN>А почему именно void*, что мешало обычные указатели использовать?

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

NBN>>Я тоже писал, под ту же портянку платформ. Ничего не мешает тебе так же использовать самописные ливы

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

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

А это по любому надо для кроссплатформенных разработок

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

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

KP>>>мне кажется, стоит поработать над методиками изучения. работать с Emacs можно после 2-3 дней его изучения и расппечатывания шпаргалки.
C>>Чем мне эти шпаргалки помогут, если у меня не работает нормально отладчик в нем? Хоткеи я и так прекрасно могу запомнить.
L>Может, для начала следует научиться писать код так, чтобы не было необходимости в отладчике?

Кстати, возьму на вооружение прием. Как скажут, что 'а вот гавно у вас редактор в студии', так я сразу отвечу 'а слабо программировать так, чтоб не пользоваться редактором'? А, а??? Воооот...

З.Ы. Лично я оченна радовался (давненько) когда увидел KDevelop (это были первые версии). В нем и справка была на МСДН похожая, вся такая интегрированная, гипертекстовая (ага, не юникс-вей, зато очень удобно). Правда КДевелоп почему-то падал постоянно.

[EOF]

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

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

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

KP>Лично мне не важно, понятен ли интерфейс любому, кто видит его в первые. Важно понятен ли он мне и насколько удобен в использовании. На данный момент, возможности которые предоставляет Emacs превосходят возможности VS и мне этого достаточно для выбора редактора кода. Хотя сам начинал с VS и тоже был очень доволен предоставляемыми возможностями редактирования. Только вот постепенно изобили окон стало раздражать, лазить за мышкой стало лень, а настроить все полностью на клавиатуру в студии довольно проблематично.

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

кстати, если ставить его версию под винду, то как он поможет мне в разработке? его ж можно будет использовать только как редактор или отладка тоже будет работать? он перекроет по возможностям VS 2005 ?

[EOF]

карандаш?

[EOF]

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

>> Ну ткни что ли неуча в какой-нить FM, где, к примеру, сказано, как в студии моментально перепрыгнуть на парный открывающий/закрывающий символ? В виме — % (подозреваю, что для этого таки есть какая-то особенно извращенная распальцовка, да вот не нашел нигде)

S>Ctrl+]

Заметьте, что когда отвечают по существу, то дискуссия в под-ветке прекращается, а так только вопли везде, что студия не умеет то, не умеет это...

А в общем, то чего она не умеет, так может оно и даром не надо? Это как с Неуловимым Джо.

Особым ценителям в руки дается встроенный макроязык (ну, бейсик, а что?).

[EOF]

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

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

AJD>>Здравствуйте, kaa.python, Вы писали:

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

AJD>>Настоящие перцы в блокноте (или аналоге) код пишут.

sc>А самые настоящие в copy con hello_world.cpp

sc>Тоже столкнулся несколько лет назад с проблемой нормальной IDE, именно IDE, а не редактор кода, на юникс/линукс.
sc>До сих пор вопрос открыт

По сравнению с VS все остальное отстой. Но приходиться жрать этот чертов кактус

KDevelop не то? (сам на него даааавно смотрел)

[EOF]

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

A>Это к чему сказано? И как это подтверждает или опровергает тезисы выше по стеку?

Я только читать начал, а тут стэкъ оверфлоф.

[EOF]

WH>При наличии общего опыта и светлой головы освоить линукс или что либо другое не составляет труда. Вобще.

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

Тут всякие разные обстоятельства бывают. Может быть, например, "бесптичье", когда ищут-ищут полгода Senior Linux C++ (а не PHP/Perl) программиста (а не сисадмина), да не могут. Тут да, любую мало-мальски светлую голову возьмешь.

А может быть ровно иначе. А именно — открывается проект под Линукс (пусть даже и порт с виндов), и нужен "линуксист" для дачи старта проекту. Тогда нужен готовый линуксный гуру.

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

Потому такая заява на вакансию заставляет предположить, что нужен именно _состоявшийся_ спец по Линуксу, т.е. компания покупает на рынке труда не просто светлую голову, а готовый линуксный опыт, чтобы избежать траты времени на его наработку внутри компании. И нужен тут не PHPшник-перловик, и не сисадмин (таких довольно много), а именно Си++ девелопер, что есть экзотика.

R>Все равно все работает на одном и том-же железе, везде одинаковый код, одинаковые механизмы страничной адресации, одинаковый стандартный С++.

...одинаковые сокеты и особенно select, одинаковый асинхронный ввод-вывод, одинаковые сетевые стеки, одинаковый UI, одинаковые threads, одинаковое управление процессами, одинаковый XML парсер... gcc у нас тоже абсолютно одинаков с микрософтным CL

И главное — одинаковые типичные паттерны решения конкретных программистских задач

всегда и во всем одинаковые.

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

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

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

R>Спроры про среду разработки считаю маразмом — среднеиндустриальные показатели числа строк кода на человека < 100 строк в день.

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

C>Собственно, после работы с GDB я понял, почему люди считают отладочную печать лучше, чем использование отладчика. Просто она действительно намного удобнее GDB.

Тот же WinDbg, вид сбоку, только _все_ команды называются там иначе, чем в WinDbg.

Вывод: у человека, который уже привык к GDB, будет совсем иное мнение о его удобстве.

WH>А если этот Вася автор сторонней либы? И живет этот Вася на другом конце планеты?
WH>1)Только не надо гнуть пальци и говорить что сейчас мы это поделье быстреньке перепишем.
WH>2)Или найдем что-то лучше.
WH>1)Не реально. Ибо там ну очень много написано. И переписывать это ооочень долго.
WH>2)Эта поделка лучшее из того что доступно.

Угу. Типичный срок — полгода. В коробочном софте это необходимость, в "точечных" решениях конкретному кастомеру на конкретную площадку — безумие.

В случае алгоритмических же либов, которые при этом не опен-сорс, может и вообще быть невозможно.

Здравствуйте, Maxim S. Shatskih, Вы писали:

не надо драматизировать — разница меньше чем между с++ и дотнет

и потом только идиот наймет только (или по большей части) виндузятников на юниховый проект
но соотншение 1 виндузятник на 2 линуховедов вполне нормально и позволит не наступать на грабли

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Можно рассчитывать только на 1 вещь
-при полностью корректных данных на входе, скорее всего все работает

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

Если тов WolfHound действительно имеет дело с кластерами (я имел с ними дело всего пару лет и в довольно скромных масштабах) то он имеет полный объем гемора с последними пунктами.
И я с ним согласен т.к. на моей памяти был случай когда мы огребли больше всего проблемм из-за покртыой тестами маленькой либы которая страдала всеми описанными недостатками (кроме работы с оборудованием)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Интересно отметить, что Ваше непонимание того, в чем реальная польза UT, растет в определенном смысле из "интергрированного отладчика". А что, действительно велик соблазн по-быстрому набросать код, расставить брякпоинты, пройтись по коду с парой входных значений и посмотреть, получили ли то, что хотели. Только вот Вы забываете, что компьютер — это такая машина для автоматизации рутины. Юнит-тесты помогают автоматизировать то, что Вы привыкли делать руками в "интегрированном отладчике", причем несмотря на необходимость писать дополнительный код теста, размер которого порой на порядок превышает тестируемый код, экономия времени и прочих ресурсов вроде нервов в итоге окзаывается колоссальной.

Правильный подход ИМХО — это Юнит-тесты + интегрированный отладчик. Как раз при прогоне юнит-теста вылетает исключение и мы тут же начинаем смотреть стек, переменные и т.п. в "интергрированном отладчике".

В общем не "unit tests vs отладчик", а "unit tests + отладчик".

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

WH>В том что тут было высказано мнение что Linux это что-то особенное... меж тем изучение линукса ничем не отличатся от изучения MFC или какой либо иной библиотеки.

Т.е. нет разницы между платформой и библиотекой?

Совершенно неверно.

Библиотеку можно учить _не всю_. Я от MFC брал то, что мне нужно, и не пользовался ничем другим.

С платформой так не выйдет. Делаешь вроде то же самое, что под виндами, а работает иначе.

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

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

R>Можно рассчитывать только на 1 вещь
R>-при полностью корректных данных на входе, скорее всего все работает

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

+1

Великолепный пост о том, чем плохи юнит-тесты, а значит, и test-driven development.

Я сам использую юнит-тесты только там, где цена баги крайне высока. Т.е., если там будет баг, то я упыхаюсь его вылавливать.

Пример: у меня было свое AVL tree, еще под ядро НТ4. По сей день есть. Все обвешано юнит-тестами.

С многонитевостью, кстати, довольно просто. Юнит-тестируется _под локами_, т.е. там, где все всегда однонитево. Потом юнит-тестированный код окружается локом — и вперед.

Зависимость от данных на входе у того когда тоже была слабая. Что там AVL tree структур из 2 чисел — менятся могут только 2 числа. Вот был бы это парсер...

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Правильный подход ИМХО — это Юнит-тесты + интегрированный отладчик. Как раз при прогоне юнит-теста вылетает исключение и мы тут же начинаем смотреть стек, переменные и т.п. в "интергрированном отладчике".
АХ>В общем не "unit tests vs отладчик", а "unit tests + отладчик".
Так я о чем и говорю. Только у меня на последних трех проектах второе слагаемое в выражении "unit test + отладчик" постоянно норовило сократиться

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

T>карандаш?

Гугль отменили?

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

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

AJD>>>Если для документирования, а-ля doxygen, то это все шоткатами генерится, включая имя и параметры. А еще зачем?
L>>Банально в блоке \code..\endcode написать пример использования.

AJD>Обычно я этот кусок кода беру уже из готового рабочего примера, поэтому необходимость как-то не возникает

Увы, не всегда возможно.

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

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

L>>Ну научи, дорогой, как включить автодополнение кода, работающее внутри блока комментария.
WH>Какой процент времени у тебя уходит на то чтобы набить код в комментариях? Что-то мне подстказывает что 0.1% максимум.
В vim даже меньше. Только вот не стоит недооценивать важность таких комментариев не следует, особенно в коллективной разработке.
WH>Какого еще сфероконя типа кода в комментариях и копирования ровно 100 строк выдумаешь?
Ну, если это для тебя сфероконь...
WH>Кстати кстати ты так и не ответил где логическая связь между D и C?
А нету ее. А каково логическое значение Ctrl-V и чем оно лучше "p"?
WH>В большинстве виндовых редакторов вобще и в студии в частности есть комманды для навигации по тексту.
Команды?
WH>Если держать shift то они превращаются в комманды выделения текста.
WH>А с выделенным текстом можно сделать кучу всяких разных действий.
Какие, например? Кроме скопировать/удалить/отформатировать?

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

L>>А Вы предпочитаете оставить утечку памяти?
WH>Я предпочитаю найти ошибку, пропатчить либу и отправить патч автору.
WH>Ибо мне нужна система которая работает, а не стоять и крчать "Я тут не причем! Это все Вася!".
Что-то Вы тут сравниваете мягкое с теплым. Какое это имеет отношение к юнит-тестированию?
L>>Знаешь, когда я пишу код, у меня первая мысль "а как я его буду тестировать". Применяя такой подход, можно половину намеченного кода, как говрят математики, свести к предыдущей задаче, т.е. использовать код, уже написанный для чего-то еще и соответственно уже оттестированный. Более того, если код таков, что натянуть на него юнит кажется невозможной или очень сложной задачей, это однозначный показатель того, что коду нужен рефакторинг.
WH>Иногда не код такой. А задача такая.
Задачу нужно дробить на части. Мы ведь тут решаем задачи, а не бросаемся с валенком на танки?
WH>Например у тебя на входе есть огромное дерево. И на выходе дерево но еще больше.
И код обработки дерева засунут в одну функцию, надо полагать? Или состоит из множества сущностей поменьше? Вот их-то и надо протестировать на предмет ошибок вроде

while (i=SOME_MAX_VALUE)  // "=" вместо "=="
{
}

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

WH>Писать код который сравнивает результат с тем что ожидалось?
Да. Еще можно, к примеру, написать генератор.
WH>Но это десятки если не сотни килобайт кода на каждый тест.
И что? Ручками сравнишь быстрее?
L>>Я тебе сейчас одну обидную вещь скажу, но советую над ней подумать. Если ты не понимаешь, как протестировать свой собственный код, ты не понимаешь как он работает.
WH>Я просто не хочу писать метры кода на ровном месте.
Погоди, пятью строчками у тебя алгоритм обработки дерева, который ты не знаешь, как тестировать, а тут вдруг "не хочу писать метры кода?" Вот уж правда, говорят "не могу", подразумевают "не хочу".
WH>Ибо в них тоже может быть ошибка.
Может. Не ошибается вообще только тот, кто ничего не делает.
L>>Подобные вещи покрываются автоматическими тестами на раз.
L>>Вот когда отрастает необходимость тестировать что-то сетевое и проверить, а что, если "Вася Пупкин, разжалованный в уборщики, выдернет сетевой кабель", приходится подумать подольше. Хотя это тоже реализуемо.

WH>Это гораздо проще чем сидеть и долбить ручками код который проверяет огромное дерево.
Кстати, что он там такое проверяет?
WH>Это я тебе говорю как человек у которого в тз одним из первых пунктов идет: "Кластер должен работать если чать кластера физически выдет из строя."
WH>И мои кластеры работают.
Бум пиписьками меряться?

WH>Так чем же плох вариант: Написать, отладить, сделать кучу дампов, отсмотреть их на предмет совпадения с тем что ожидали. После чего засунуть эти дампы в svn и автоматически находить регрессии.

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

WH>Кстати еще одна задача которую не понятно как тестировать: Автоматическое улучшение изображений.
Вы точно уверены, что знаете, что такое юнит тест?
Юнит-тесты тестируют не систему целиком, а ее минимальные части для уверенности, что вы не положили в фундамент плохих кирпичей. Тестировать алгоритмы в общем случае — не их задача.
WH>Результат совершенно субъективен.
WH>Объективные метрики полностью отсутствуют.
Это не задача для юнит-тестирования. Это функциональное тестирование.

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

T>кстати, если ставить его версию под винду, то как он поможет мне в разработке?

Исключительно как редактор. Как очень хороший редактор. После того как вы потратите довольно много времени на его допиливание.

T> его ж можно будет использовать только как редактор или отладка тоже будет работать?

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

T>он перекроет по возможностям VS 2005?

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>показал, который делает то же самое. Я бы свою поделку нафиг выбросил.
Приведи мальенькое ТЗ или лучше кусок кода, я попробую примерчик нарисовать, для перехода к полноценной дискусси.
В спорах истина рождается, однако.
>> Попробуйте изменить подход к "покрытию юнит-тестами".
C>Куда? В третий раз напомню — код библиотеки почти на 100% покрыт
C>тестами. Почему же мне не помогает эта магическая серебряная пуля?
Если в сердце дверь закрыта, можно в печень постучаться (где-то подслушал)
>> Бывает. Еще можно лог к программе приделать.
C>Приделан. Ничерта не помогает. Тем более, что писать в лог сложные
C>графовые стркутуры — это еще то занятие.
Ну... перегрузить операторы вывода для узла структуры не помогает?

R>>-для многопоточных приложений никаких гарантий нет
L>Почему?

Потому что неизвестно, где именно кернел переключит нитку. Искать race conditions юнит-тестами — это бред. Они ищутся только вычиткой кода, ну или ловятся на живой глюкнувшей системе

. Лучше их вообще не допускать.

Юнит-тестируестя то, что внутри себя однонитево, например — будет использоваться только из-под лока.

L>А кто запрещает написать юнит тест, который тестирует работу алгоритма, подавая ему мусор на вход?

Перебрать все возможные виды мусора — это крайне сложно, зачастую — невозможно.

L>Нештатная ситуация это что? Computer on fire? Ошибка ввода-вывода? Крах ОС?

Ошибка любого вызова, сделанного "вбок" в другие компоненты или "вниз" в платформу. Я понимаю, что есть технологии типа Low Resources Simulation в Driver Verifier, но они под эту симуляцию пол-ядра отпатчили

L>У меня опыт сугубо противоположный — стоит что-нибудь не покрыть юнит тестом (ну, надо быстро сделать, это просто и т.п.), как моментально из этого кода отрастают трудноуловимые грабли.

Так вот, 80% кода — это просто

если очень аккуратно его писать — грабли почти никогда не вылезают, разве что ну-очень-сильно-corner-cases.

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

L>Что-то Вы тут сравниваете мягкое с теплым. Какое это имеет отношение к юнит-тестированию?
Такое что для того чтобы это исправить нужен отладчик.

То, что вы делаете в отладчике, легко автоматизируется юнит тестом...

Далеко не все автоматизируется юнит тестом...

L>И код обработки дерева засунут в одну функцию, надо полагать? Или состоит из множества сущностей поменьше? Вот их-то и надо протестировать на предмет ошибок вроде
L>банальных проблем выделения/освобождения памяти и прочих глупых, обидных, но трудноулавливаемых косяков.
1)Подобные опечатки у меня бывают пару раз в год. А когда у меня последный раз память текла или там проезд был я уже и не помню.
2)Для того чтобы протестировать некоторую функцию нужно подготовить для нее данные. Что далеко не всегда просто.
3)Не знаю как у тебя но у меня детали реализации по ходу дела часто и сильно меняются. И если тестировать их то придется постоянно переписывать тесты. И уж точно я не знаю как именно у меня будет выглядить код до того как я его напишу. До начала работы у меня есть только примерный план и (не всегда) внешние интерфейсы.
4)Я в данный момент пытаюсь допинать до рабочего состояния (устранив проблемы с крайними случаями на которые забили торетеки) очередной алгоритм обработки изображения. Подобных ошибок там нет. Но легче от этого не становится.

L>Да. Еще можно, к примеру, написать генератор.
А зачем мне два генератора?
У меня уже есть один. Сама программа...
Сделать печать результата тривиально. А вот получить сам результат...

L>Погоди, пятью строчками у тебя алгоритм обработки дерева, который ты не знаешь, как тестировать, а тут вдруг "не хочу писать метры кода?" Вот уж правда, говорят "не могу", подразумевают "не хочу".
Не возможно очень часто означает не технически не возможно, а то что это оооочень дорого.
Вроде не маленький. Должен знать такие простые вещи.

WH>>Это гораздо проще чем сидеть и долбить ручками код который проверяет огромное дерево.
L>Кстати, что он там такое проверяет?
Проверяет он то что на выходе то что ожидалось.

L>В принципе, твой подход тоже применим, но нужно как-то показать стабильность алгоритма (иначе твой тест будет доказывать лишь то, что алгоритм работает для отдельной конечной области значений на входе)
Любой. Те абсолютно любой тест. Доказывает это и только это.
Болие сильные гарантии может дать только формальное доказательство. Но это очень дорого и не всегда возможно (например если у результата есть субъективные характеристики).

L>и обязательно организовать проверку поведения при некорректных данных на входе.
Тут все просто. В этом случае вылетит исключение...

L>Вы точно уверены, что знаете, что такое юнит тест?
Я знаю.
Но тут кто-то утверждал что дебагер ваще не нужен...

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

R>>-для многопоточных приложений никаких гарантий нет
L>Почему?
Юнит тесты для недетерминированных систем... это что-то новое...
Проверить работу даже двух потоков во всех возможных сочетаниях практически не реально. Почему объяснять надо?

R>>-при корректных но не предусмотреных тестами данных никаких гарантий нет и анализ покрытия н юниттесты не скажут вам об этом если нет кода по обработке специфическог юзкейса
L>Это вопрос о программировании юнит-теста и стабильности алгоритма. Иногда есть смысл проверить на всем диапазоне значений, иногда это невозможно.
Я бы сказал что проверить на всем диапозоне входных данных можно исчезающи малое колличество алгоритмов.
Уже при паре Int32 проверить на всех входных значениях почти не реально.
А если на входе картинка

Думаю всю чудовищьность числа 2 ^ (1024 * 768 * 32) сможешь предствавить сам...

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, Maxim S. Shatskih, Вы писали:

WH>>В том что тут было высказано мнение что Linux это что-то особенное... меж тем изучение линукса ничем не отличатся от изучения MFC или какой либо иной библиотеки.
MSS>Т.е. нет разницы между платформой и библиотекой?
MSS>Совершенно неверно.
Мой опыт перехода под линукс говорит что очень даже верно...

MSS>Библиотеку можно учить _не всю_. Я от MFC брал то, что мне нужно, и не пользовался ничем другим.
MSS>С платформой так не выйдет. Делаешь вроде то же самое, что под виндами, а работает иначе.
Гм. Чтение доков перед использованием уже отменили?

MSS>Я уж не говорю про билд-платформу, ее поддержка тоже есть немалый труд.
Гм. ИМХО вобще не проблема.
Один раз туториал прочитал и дальше только иногда в маны поглядываешь...

MSS>Под линуксом можно сделать в принципе практически все, что под виндами, и наоборот. Но конкретные тулы для этого сделать — сильно разные.
И? Чем это отличается от перехода на не знакомую библиотеку?

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

L>В vim даже меньше. Только вот не стоит недооценивать важность таких комментариев не следует, особенно в коллективной разработке.
Я не про ценность данных комментариев. А про ценность автоматизаци операции которая занимет меьше 0.1% времени.

WH>>Какого еще сфероконя типа кода в комментариях и копирования ровно 100 строк выдумаешь?
L>Ну, если это для тебя сфероконь...
Ну тогда просвети зачем тебе нужно скопировать ровно 100 строк и при этом ты точно знаешь это число зарание.
Учитывая что тебе это нужно регулярно (инче ты бы на этом не настаивал) у тебя не возникнет проблем с парой примеров.

Вот я никогда не знаю сколько строк мне нужно скопировать. Я знаю что мне нужно скопировать от и до. Но сколько там строк

WH>>Кстати кстати ты так и не ответил где логическая связь между D и C?
L>А нету ее. А каково логическое значение Ctrl-V и чем оно лучше "p"?
Причем тут Ctrl-V?
Я говорю про конкретные операции в студии и виме.
В студии есть перемещение к концу строки end.
Есть режим выделения shift.
Их сочетание дает выделение до конца строки.
Если добавить сюда del то получим удаление текста до конца строки.
А если Ctrl-V то получим замену текста до конца строки на то что было в буфере.

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

А вот зная про то что есть D догадаться до того что есть C не реально.

L>Какие, например? Кроме скопировать/удалить/отформатировать?
Например можно провести замену в том числе по регулярному выражению в приделах выделения.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

KP>Исключительно как редактор. Как очень хороший редактор. После того как вы потратите довольно много времени на его допиливание.
А зачем? Если можно взять студию и получить очень хороший редактор без допиливания?

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

WH>Здравствуйте, kaa.python, Вы писали:

KP>>Исключительно как редактор. Как очень хороший редактор. После того как вы потратите довольно много времени на его допиливание.
WH>А зачем? Если можно взять студию и получить очень хороший редактор без допиливания?

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

как быть во всех этих случаях?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Интересно отметить, что Ваше непонимание того, в чем реальная польза UT, растет в определенном смысле из "интергрированного отладчика". А что, действительно велик соблазн по-быстрому набросать код, расставить брякпоинты, пройтись по коду с парой входных значений и посмотреть, получили ли то, что хотели. Только вот Вы забываете, что компьютер — это такая машина для автоматизации рутины. Юнит-тесты помогают автоматизировать то, что Вы привыкли делать руками в "интегрированном отладчике", причем несмотря на необходимость писать дополнительный код теста, размер которого порой на порядок превышает тестируемый код, экономия времени и прочих ресурсов вроде нервов в итоге окзаывается колоссальной.

Угу вот только и современные интегрированные отладчики и юнит тесты имеют один общий корень — Smalltalk

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

C>С Symbian'ом ничего больше не совместимо из-за их самопального механизма LEAVE'ов.

Кстати, я вспомнил. Основная проблема при написании кроссплатформенного кода для симбиана — вовсе не в исключениях, а системе callback. Эти калбеки иногда сильно меняют архитектуру программы.
Правда мне очень нравится программировать с использованием их парадигмы, за это я прощаю симбе их жуткий С++.

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

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

L>>Что-то Вы тут сравниваете мягкое с теплым. Какое это имеет отношение к юнит-тестированию?
WH>Такое что для того чтобы это исправить нужен отладчик.
WH>

То, что вы делаете в отладчике, легко автоматизируется юнит тестом...

WH>Далеко не все автоматизируется юнит тестом...
Тестирование всего, кроме GUI, можно автоматизировать. Уровней можно придумать сколько угодно — проверка кода на корректность поведения в юнит тестах, функциональные тесты, основанные на юнит-тестах и т.д. Если нечто, что не имеет никаких ручек, торчащих навстречу пользователю, "не автоматизируется", то надо сделать так, чтобы автоматизировалось. Особенно в случае коллективной разработки.
L>>И код обработки дерева засунут в одну функцию, надо полагать? Или состоит из множества сущностей поменьше? Вот их-то и надо протестировать на предмет ошибок вроде
L>>банальных проблем выделения/освобождения памяти и прочих глупых, обидных, но трудноулавливаемых косяков.
WH>1)Подобные опечатки у меня бывают пару раз в год. А когда у меня последный раз память текла или там проезд был я уже и не помню.
А ты один код пишешь или есть еще Х, нет Y девелоперов?

Здравствуйте, Maxim S. Shatskih, Вы писали:

R>>>-для многопоточных приложений никаких гарантий нет
L>>Почему?

MSS>Потому что неизвестно, где именно кернел переключит нитку. Искать race conditions юнит-тестами — это бред. Они ищутся только вычиткой кода, ну или ловятся на живой глюкнувшей системе

. Лучше их вообще не допускать.
Можно симулировать ситуацию, провоцирующую возникновение гонок и/или дедлоков. Естественно, характерную для конкретного кода. Сам делал, делаю и буду делать. Только это уже не юнит тест в обычном его понимании, хотя очень удобно включается в состав юнит-тестов.

MSS>Юнит-тестируестя то, что внутри себя однонитево, например — будет использоваться только из-под лока.
L>>А кто запрещает написать юнит тест, который тестирует работу алгоритма, подавая ему мусор на вход?
MSS>Перебрать все возможные виды мусора — это крайне сложно, зачастую — невозможно.
Хм.. что это за алгоритм такой, который выбирает, хороший мусор ему дали или плохой? Если данные не валидны — поведение одно, если валидны — другое.
L>>Нештатная ситуация это что? Computer on fire? Ошибка ввода-вывода? Крах ОС?
MSS>Ошибка любого вызова, сделанного "вбок" в другие компоненты или "вниз" в платформу. Я понимаю, что есть технологии типа Low Resources Simulation в Driver Verifier, но они под эту симуляцию пол-ядра отпатчили

L>>У меня опыт сугубо противоположный — стоит что-нибудь не покрыть юнит тестом (ну, надо быстро сделать, это просто и т.п.), как моментально из этого кода отрастают трудноуловимые грабли.
MSS>Так вот, 80% кода — это просто

если очень аккуратно его писать — грабли почти никогда не вылезают, разве что ну-очень-сильно-corner-cases.
Очень аккуратно вот ты можешь писать очень аккуратно, я тоже могу писать очень аккуратно. Гарантирует ли это, что остальные 10 девелоперов пишут так же аккуратно и не забывают освобождать память, не используют EnterCriticalSection явно вместо Scope guard и т.д?

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

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

R>>>-для многопоточных приложений никаких гарантий нет
L>>Почему?
WH>Юнит тесты для недетерминированных систем... это что-то новое...
WH>Проверить работу даже двух потоков во всех возможных сочетаниях практически не реально. Почему объяснять надо?
Опять непонимание того, кто такой юнит тест. Нет смысла тестировать всю систему, если нет уверенности в том, что она не собрана из гнилых кирпичей. Более того, у двух потоков могут быть лишь два интересных взаимных состояния — когда они обращаются к разделяемым данным и когда не обращаются.
R>>>-при корректных но не предусмотреных тестами данных никаких гарантий нет и анализ покрытия н юниттесты не скажут вам об этом если нет кода по обработке специфическог юзкейса
L>>Это вопрос о программировании юнит-теста и стабильности алгоритма. Иногда есть смысл проверить на всем диапазоне значений, иногда это невозможно.
WH>Я бы сказал что проверить на всем диапозоне входных данных можно исчезающи малое колличество алгоритмов.
WH>Уже при паре Int32 проверить на всех входных значениях почти не реально.
2^64
WH>А если на входе картинка

Думаю всю чудовищьность числа 2 ^ (1024 * 768 * 32) сможешь предствавить сам...
Еще раз, по буквам — можно и нужно тестировать составные части того, что на вход принимает картинку, даже если проверку работы всего принимающего картинки автомата автоматизировать не удается.
L>>У меня опыт сугубо противоположный — стоит что-нибудь не покрыть юнит тестом (ну, надо быстро сделать, это просто и т.п.), как моментально из этого кода отрастают трудноуловимые грабли.
WH>А у меня все серьезные проблемы отрастают исключительно на этапе интеграции нескольких систем которые псали разные люди.
А у меня таких проблем не было уже давно, благодаря подходу к архитектуре и наличию простых правил тестирования модулей.

MSS>>Перебрать все возможные виды мусора — это крайне сложно, зачастую — невозможно.
L>Хм.. что это за алгоритм такой, который выбирает, хороший мусор ему дали или плохой?

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

L>Очень аккуратно вот ты можешь писать очень аккуратно, я тоже могу писать очень аккуратно. Гарантирует ли это, что остальные 10 девелоперов пишут так же аккуратно и не забывают освобождать память, не используют EnterCriticalSection явно вместо Scope guard

Мне scope guards не нужны — у меня и так ни разу забытого лока не было за 8 лет ковыряния в ядре виндов.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>>>Перебрать все возможные виды мусора — это крайне сложно, зачастую — невозможно.
L>>Хм.. что это за алгоритм такой, который выбирает, хороший мусор ему дали или плохой?

MSS>Баг может возникнуть только в случае _неких специальных видов мусора_, часто неизвестных тестеру.

Хм.. это такой мусор, замаскированный под корректные данные, что ли?

L>>Очень аккуратно вот ты можешь писать очень аккуратно, я тоже могу писать очень аккуратно. Гарантирует ли это, что остальные 10 девелоперов пишут так же аккуратно и не забывают освобождать память, не используют EnterCriticalSection явно вместо Scope guard

MSS>Мне scope guards не нужны — у меня и так ни разу забытого лока не было за 8 лет ковыряния в ядре виндов.

А остальные 10 девелоперов в команде такие же гении?

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

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

WH>>Уже при паре Int32 проверить на всех входных значениях почти не реально.
L>2^64
1)Я считать умею.
2)Если алгоритм не a + b это уже очень не быстро.

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

Про различные алгоритмы улучшения изображений я вобще молчу. Они совершенно не формализуемы.
Их разработка сводится к массе эксперементов и выкручивании формул так чтобы результат был такой как надо даже в крайних случаях.

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

Ты один программы пишешь?
Вон недовно поймали критического таракана...
Жил на стыке 3х систем.
Причем каждая система работала как задумано. Те не только юнит но и болие высокоуровневые тесты ничего не могли найти в принципе. Разве что интеграционные. Но данный вариант поведения пользователя просто в голову не пришол.
Починил маааленьким изменением логики. Буквально добавил 2 строки... тесты пострадали гораздо сильнее...
Тот кусок кода куда добавил те пару строчек я разве что формально не доказал...
И я бы доказал. Жаль что С++ к этому не преспособлен. Вот только данную проблему это бы не решило...
Ибо доказывают не отсутствие ошибок (это не формализуемое понятие), а определенные свойства системы. И я бы их доказал. Только нужны были практически идентичные но другие свойства...

... << RSDN@Home 1.2.0 alpha rev. 673>>

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	05.07.07 12:00
Оценка:	10 (5) +4 -5

	От:	AntZ
	Дата:	05.07.07 16:10
	Оценка:	3 (2) +2 -9

	От:	machine3000
	Дата:	05.07.07 11:50
	Оценка:	+4 -4

	От:	WolfHound
	Дата:	06.07.07 13:46
	Оценка:	2 (2) +4

	От:	landerhigh
	Дата:	10.07.07 06:15
	Оценка:	-3

	От:	NikeByNike
	Дата:	05.07.07 16:20
	Оценка:	1 (1)

От:	Anatolix	https://www.linkedin.com/in/anatolix/
Дата:	06.07.07 14:31
Оценка:	1 (1) +1

От:	Didro	home~pages
Дата:	05.07.07 12:42
Оценка:

	От:	Ушастый Ёж
	Дата:	08.07.07 22:30
	Оценка:	+1

	От:	Веселый кролик
	Дата:	05.07.07 14:30
	Оценка:

	От:	Maxim S. Shatskih
	Дата:	05.07.07 18:16
	Оценка:

	От:	Правдоруб
	Дата:	06.07.07 18:49
	Оценка:

От:	_Obelisk_	http://www.ibm.com
Дата:	12.07.07 07:01
Оценка:

	От:	Андрей Хропов
	Дата:	15.07.07 21:59
	Оценка:

От:	dr.Chaos	Украшения HandMade
Дата:	03.09.07 11:40
Оценка:

	От:	Left2
	Дата:	13.07.07 08:31
	Оценка:	+1 -1

	От:	Alex Alexandrov
	Дата:	05.09.07 19:47
	Оценка: