Пришел в интересную компанию в небольшую команду (5 чел).
Проект интересный, сложный, команда распределенная. Первая фаза — еще 6 мес. Дальше доработки еще год как минимум. (чтобы было понятно, что "тяп-ляп" тут будет больно).
Через месяц понял, что "команда" раз за разом принимает решения, от которых у меня волосы дыбом становятся. Решил спросить стороннего мнения – это я такой «неуживчивый» или действительно решения непрофессиональные. С одной стороны — ну явно как-то не "по-взрослому", а с другой — если один против всех, то чаще не прав — один? Хотя не скажу что против всех — как правило я пытаюсь показать недостатки решения кому-то одному а остальные — заняты своими делами.
Решения, выносимые на ваш суд:
1. На мой вопрос почему не собирается релиз-версия и предложение заняться этим был ответ, что этим занимается другой чел. (Ну не проблема, у меня действительно свои задания есть). Через 3 недели был назначен преальфа релиз и в пятницу, накануне этого релиза оказалось, что релиз-версия падает при запуске. Тот чел начал биться над этой проблемой. Я узнал об этом только ближе к вечеру, позвонил ему и сказал что в таких случаях обычно первым делом отключается оптимизация и по-чуть чуть добавляется отладочная информация. Он сказал, что хорошо, только не падает при запуске под средой и он уже выловил место с помощью трассировки и причина непонятна. После этого я взял проект главного приложения, отключил оптимизацию, добавил отладочную инфу – не падает. Ну, для преальфы сойдет – так и ушло в инсталляцию (не знаю смотрел ли кто-то на проблему после)
2. (С++ specific) Решение подключать прекомпиленные заголовки (precompiled headers) во все проекты. Я говорю, что у меня есть опыт и хочу это сделать. Ответ: «уже этим занимается другой чел. Позвони ему и скажи если есть что посоветовать» Звоню, говорю, что обычно нужно смотреть на результат работы препроцессора и будет ответ что включать в заголовок. Поспорили на счет того убирать ли инклуды из исходников (я — за то чтобы оставить). Видя что аргументов не хватает (действительно для меня это было очевидной вещью, а ведь тяжело придумывать обоснования для очевидного), я выразил сожаление, что он не согласен, но спорить перестал ввиду бесперспективности. В итоге он просто перенес во всех библиотеках include <> из исходников в stdafx.h и на результаты работы препроцессора не смотрел. Это привело к двум проблемам:
a. проекты перестали собираться под Linux (я был уверен, что он делал и для gcc)
b. половина системного кода не была включена в заголоки.
c. Перестали собираться пару минорных проектов, которые не были затронуты измерениями — в них стало не хватать инклудов.
Но больше всего меня поразило то, как была исправлена первая проблема – заголовки были возвращены в исходники, но обернуты #ifndef _Win32 …
3. Решение изменить output директорию для поектов. Был введено два диска U: и V: на один – объектники, а на другой – бинарники. У меня опять волосы дыбом и как-бы аргументов нет. Говорю давайте я переделаю на «переменные сети окружения» — завязался спор – что лучше... Основных аргумента против было два:
a. Для изменения envvar нужна перезагрузка (как минимум VisualStudio), а для диска – «простой subst».
b. Непонятно как менять, ведь $(OutDir) – может быть и абсолютный каталог, и относительный, а проекты лежат на разных уровнях.
Я сказал что моя цель:
a. чтобы собиралось и с переменной и без (т.е. можно не задавать ее вообще)
b. чтобы можно было использовать две версии системы одновременно (- ответ «зачем такая экзотика» – опять волосы дыбом).
c. не создать проблемы тем, у кого на диске U: что-то висит.
d. Проблему b) решить можно
В итоге чела вроде не убедил, но лидер сказал «давай сделаем так, чтобы что-то сетапить не обязательно». И опять делать не мне (наверно правильно новичкам не доверять). Вроде он сделал, но опять что-то не работает, и не особо разбираясь эти изменения откатили и теперь я не могу использовать две версии одновременно и обязвтельно должен иметь диски U и V
5. Организация авто-тестов в DLL. Видя что для юнит-тестов существует один проект (почти самописный NUnit), который будет линковать все остальные DLL, я высказал мнение, что «тест engine» не должен ни от чего зависеть, а тесты – сидеть в тех же библиотеках что и тестируемый код (но компилиться только опционально) увидел полное непонимание со стороны коллег
6. для проверки условий в тестах есть макрос типа Check(explanation_string, condition). Я сказал, что в коде таким пользоваться неудобно: во-первых, если в тесте десятки проверок, то придумывать каждый раз строку для объяснения – непрактично, во-вторых — если вначале строка, а справа — условие, то такой код читать неудобно. Написал свой макрос #define MyCheck(condition) Check(#condition, condition). В ответ – тоже непонимание типа «какждый кто приходит придумывает свои правила». Дыб опять.
Есть еще другие моменты, которые я не до конца понимаю, это было остновное. Например, для связи unmanaged C++ и C# генерятся простые врапперы (они то простые, но кода уже больше 1 KLOC — это в начале разработки.) Вроде хорошо, но в начале след года нужно будет оборачивать в вебсервис и делать ту же работу заново — описывать интерфейсы на формальном языке и генерить врапперы... Не лучше ли это делать сразу и генерировать врапперы и для связи C++ и ВебСервисов и для С++ и С#...
Может ли кто-то сказать: я выпендриваюсь или мои волосы не зря дыбом становятся? (То есть, то, что волосы дыбом становятся при удивлении — не проблема. Вопрос — есть ли причина для удивления?)
C>Пришел в интересную компанию в небольшую команду (5 чел). C>Проект интересный, сложный, команда распределенная. Первая фаза — еще 6 мес. Дальше доработки еще год как минимум. (чтобы было понятно, что "тяп-ляп" тут будет больно).
Мой случай. Практически во всем.
C>Через месяц понял, что "команда" раз за разом принимает решения, от которых у меня волосы дыбом становятся.
Команда не может принимать решений. Решения принимает руководитель.
C>С одной стороны — ну явно как-то не "по-взрослому", а с другой — если один против всех, то чаще не прав — один?
Совершенно неверно. Впрочем, во внутренней реальности людей с совковыми комплексами это действительно так
C>Хотя не скажу что против всех — как правило я пытаюсь показать недостатки решения кому-то одному
Недостатки надо показывать _шефу_, а не "кому-то одному".
C>Решения, выносимые на ваш суд:
C>1. На мой вопрос почему не собирается релиз-версия и предложение заняться этим был ответ, что этим занимается другой чел. (Ну не проблема, у меня действительно свои задания есть). Через 3 недели был назначен преальфа релиз и в пятницу, накануне этого релиза оказалось, что релиз-версия падает при запуске. Тот чел начал биться над этой проблемой. Я узнал об этом только ближе к вечеру, позвонил ему и сказал что в таких случаях обычно первым делом отключается оптимизация и по-чуть чуть добавляется отладочная информация. Он сказал, что хорошо, только не падает при запуске под средой и он уже выловил место с помощью трассировки и причина непонятна. После этого я взял проект главного приложения, отключил оптимизацию, добавил отладочную инфу – не падает. Ну, для преальфы сойдет – так и ушло в инсталляцию (не знаю смотрел ли кто-то на проблему после)
Когда я вижу такую вот "работу", у меня голова кружится. Почему нет регулярного билдования? почему вообще приоритет отдается дебаг-версиям, как у первокурсника начала 90х, мучающего Турбо Си 2.0?
Практически все нажатия на кнопочку Build (или команды командной строки build и make) должны делаться _в релизную версию_. Дебаг версия строится только тогда, когда уже есть замеченный баг, и без развитых средств отладки с багом не разобраться.
Почему продукт практически никогда не запускается НЕ под средой? Кстати, еще одно преимущество build.exe над средой — нет понятия "запущено под средой", все всегда запускается почти тем же образом, что будет у юзера.
Бардак тут — капитальный. Решения а) процедуры частого билдования и хотя бы минимального тестирования на машине _с пустой ОС без среды_ б) ненавязчивый переход девелоперов на то, чтобы строить и мучать в первую очередь релизные версии.
К вам тоже серьезный вопрос. У вас проект, где "тяп-ляп" будет больно. Почему вы позволяете себе выпустить наспех залатанное в билд продукта, который будет доступен пользователям? почему не была выяснена причина бага? не получается быстро — доклад шефу, пусть он решает. Почему девелопер без шефа берез на себя ответственность выпустить серьезный майлстон с заплаткой наспех?
Тут речь о нахождении баланса между сроками выхода "майлстонного релиза" и качеством, а такой баланс может найти только человек, играющий роль ПМ, а не девелопер и не архитектор.
C>2. (С++ specific) Решение подключать прекомпиленные заголовки (precompiled headers) во все проекты. Я говорю, что у меня есть опыт и хочу это сделать.
А что — у кого-то нет такого опыта?
C>Ответ: «уже этим занимается другой чел. Позвони ему и скажи если есть что посоветовать» Звоню, говорю, что обычно нужно смотреть на результат работы препроцессора и будет ответ что включать в заголовок.
Вместо того, чтобы смотреть на инклюды в исходнике — смотрим на результат препроцессирования. Знаете, это уровень "ковыряюсь отверткой в ухе — звук пропал".
Одна из хороших эвристик, что тянется еще из MFC — в прекомпайл включать только _платформенные_, не вами написанные заголовки, т.е. те заголовки, которые вы никогда не будете редактировать.
C>Поспорили на счет того убирать ли инклуды из исходников (я — за то чтобы оставить).
Не пофиг? время на споры только тратить.
C>
C>a. проекты перестали собираться под Linux (я был уверен, что он делал и для gcc) C>b. половина системного кода не была включена в заголоки. C>c. Перестали собираться пару минорных проектов, которые не были затронуты измерениями — в них стало не хватать инклудов. C>
Ваш коллега меня просто поражает своей душевной простотой. Он вообще был в курсе, что проект надо собирать еще и под Linux? почему после внесения косметических правок, не влияющих на функционал, проект был брошен в не-строящемся состоянии?
C>Но больше всего меня поразило то, как была исправлена первая проблема – заголовки были возвращены в исходники, но обернуты #ifndef _Win32
Что это были за заголовки? специфичные для Линукса? тогда разумно.
C>3. Решение изменить output директорию для поектов. Был введено два диска U: и V: на один – объектники, а на другой – бинарники.
Мдаааа.... то есть в систему билдования жестко вшиты конкретные буквы томов? а на Линуксе это как будет работать?
C>
C>a. Для изменения envvar нужна перезагрузка (как минимум VisualStudio), а для диска – «простой subst». C>b. Непонятно как менять, ведь $(OutDir) – может быть и абсолютный каталог, и относительный, а проекты лежат на разных уровнях. C>
Вы оба хороши пользуетесь средствами билдования из Студии, а потом еще сбоку к ним ляпаете руками на соплях вписанные env vars и буквы томов.
Правильно так: а) убедиться, что в студиевском файле проекта вообще нет абсолютных путей б) создать директорию на абы какой машине абы какой глубины как рука возьмет, единственное условие — на машине должна быть Студия в) поставить эту директорию в сорс-контроле как локальную г) взять с сорс-контрола все дерево д) запустить Студию дабл-кликом на файл проекта е) нажать там кнопку Build. Все.
При наличии чужих библиотек, что не дают со Студией, все чуть усложняется.
C>В итоге чела вроде не убедил, но лидер сказал «давай сделаем так, чтобы что-то сетапить не обязательно».
Вот это слова не мальчика, но мужа.
C>И опять делать не мне (наверно правильно новичкам не доверять). Вроде он сделал, но опять что-то не работает, и не особо разбираясь эти изменения откатили и теперь я не могу использовать две версии одновременно и обязвтельно должен иметь диски U и V
Человек не исполнил команду лида, и создал вам проблемы в работе. Вы поставили лида в известность?
C>5. Организация авто-тестов в DLL. Видя что для юнит-тестов существует один проект (почти самописный NUnit), который будет линковать все остальные DLL, я высказал мнение, что «тест engine» не должен ни от чего зависеть, а тесты – сидеть в тех же библиотеках что и тестируемый код (но компилиться только опционально) увидел полное непонимание со стороны коллег
Правильно. При их подходе тестируется ровно тот же бинарь, что пойдет клиенту. Ваш подход имеет право на существование для тестирования каких-то интересных мест в пределах 1 бинаря, но для тестирования целых бинарей их подход лучше.
C>6. для проверки условий в тестах есть макрос типа Check(explanation_string, condition). Я сказал, что в коде таким пользоваться неудобно: во-первых, если в тесте десятки проверок, то придумывать каждый раз строку для объяснения – непрактично, во-вторых — если вначале строка, а справа — условие, то такой код читать неудобно. Написал свой макрос #define MyCheck(condition) Check(#condition, condition). В ответ – тоже непонимание типа «какждый кто приходит придумывает свои правила». Дыб опять.
Тоже они правы. Это лично вам неудобно так писать, а у них так принято.
Краткие выводы:
— совершенно дисфункциональная команда, скорее всего — из-за недостатка личного опыта работы у каждого. Для проекта сложного-но-на-мало-народу такое может оказаться приговором.
— по профессиональной части вы бываете и правы, по крайней мере более правы, чем другие.
— по личностной части — много идей на уровне "как нам реорганизовать Рабкрин", некоторые из которых просто пустяки — можно и так, и эдак.
— если в этой команде не будет наведен порядок — ее перспективы — и ваши в ней — туманны.
— если же порядок наведен будет, или же если вы попадете в толковую команду с таким количеством идей о реорганизации Рабкрина — вас начнут оттуда выжимать подковерными путями.
— есть определенные шансы возглавить наведение порядка в текущей команде. Сколько их — 10% или 90% — сказать сложно, очень многое зависит от личности лида и от личных отношений в команде.
ИМХО ты не прав.
Когда станешь прожект-лидером, тогда и меняй устоявшиеся порядки. На своем опыте убедился — то, что более эффективно по сути, может обернуться проблемами для проекта если люди не привыкли или не умеют так работать. Если каждый программер начинает давать советы по оптимизации труда, ничего кроме геморроя из этого не выходит.
Во-первых, спасибочки за ответ.
C>>Через месяц понял, что "команда" раз за разом принимает решения, от которых у меня волосы дыбом становятся. MSS>Команда не может принимать решений. Решения принимает руководитель.
вот тут позвольте с вами и согласиться и нет. Как бы концептуально — я полностью за, но на практике вижу не первый раз позицию "у нас хорошие спецы и я им это поручил сделать".
То есть вы советуете не связываться с такими сслучаями — это же тоже не выход?
C>>если один против всех, то чаще не прав — один? MSS>Совершенно неверно. Впрочем, во внутренней реальности людей с совковыми комплексами это действительно так
Здорово! Я почти враз поменял жизненные взгляды — уже не зря писал письмо
MSS>Недостатки надо показывать _шефу_, а не "кому-то одному".
Позиция шефа — "а ты с аффтором разговаривал? ну давай еще пообсуждаем на форуме...". Или как-то по другому, что в итоге можно перевести "Я Петю больше знаю, я его варианту больше доверяю..."
MSS>Когда я вижу такую вот "работу", у меня голова кружится. Почему нет регулярного билдования?
Я для себя на этот вопрос ответил так: "это будет первое чего я буду добиваться после завершения первого задания (но не дальше чем исп срок закончится)"
MSS>Практически все нажатия на кнопочку Build (или команды командной строки build и make) должны делаться _в релизную версию_. Дебаг версия строится только тогда, когда уже есть замеченный баг, и без развитых средств отладки с багом не разобраться.
Да согласен 100%! Ну не так просто попасть в такой проект, ведь такое достижимо только в новеньких проектах (например без паровоза 20-летних шедевров, хотя это другой случай) а реально используется в <5% существующих проектов. В остальных же кто-то работает и не так-то просто даже отработав год сдвинуть машину в это направление...
MSS>Почему продукт практически никогда не запускается НЕ под средой? Кстати, еще одно преимущество build.exe над средой — нет понятия "запущено под средой", все всегда запускается почти тем же образом, что будет у юзера.
вот решил запустить релиз на второй неделе работы — не собрался...
MSS>Бардак тут — капитальный. Решения а) процедуры частого билдования и хотя бы минимального тестирования на машине _с пустой ОС без среды_ б) ненавязчивый переход девелоперов на то, чтобы строить и мучать в первую очередь релизные версии.
+1
MSS>К вам тоже серьезный вопрос. У вас проект, где "тяп-ляп" будет больно. Почему вы позволяете себе выпустить наспех залатанное в билд продукта, который будет доступен пользователям? почему не была выяснена причина бага? не получается быстро — доклад шефу, пусть он решает. Почему девелопер без шефа берез на себя ответственность выпустить серьезный майлстон с заплаткой наспех?
Разрешите оправдаться!
Эта преальфа — не имеет никакой функцианальной полезности и выпущена скорее для высшего руководства и чтобы кто хочет поимел представление о том, как все будет выглядеть.
На счет всего остального — шеф — один из нас 5-ти (знал прекрастно и сам пытался побороть) и дальше большой скачек в иерархии до непрограммистского начальства...
C>>2. (С++ specific) Решение подключать прекомпиленные заголовки (precompiled headers) во все проекты. Я говорю, что у меня есть опыт и хочу это сделать.
MSS>А что — у кого-то нет такого опыта?
Представьте себе ни у одного из остальных (хотя и по возрасту и по опыту хор специалисты...)
C>>Звоню, говорю, что обычно нужно смотреть на результат работы препроцессора и будет ответ что включать в заголовок. MSS>Вместо того, чтобы смотреть на инклюды в исходнике — смотрим на результат препроцессирования. Знаете, это уровень "ковыряюсь отверткой в ухе — звук пропал". MSS>Одна из хороших эвристик, что тянется еще из MFC — в прекомпайл включать только _платформенные_, не вами написанные заголовки, т.е. те заголовки, которые вы никогда не будете редактировать.
Да, речь именно об этом. У нас много сторонних библиотек используется (glib, libxml, ... >30), поэтому включать именно все что инклудится с угловыми скобками (<>)
Но проблема может быть то, что я в библиотеке A.dll включаю заголовок из B.dll который включает <xmllib.h>. (что в итоге и было в нашем случае). Узнать о том, что какой-то файл не включен можно только с помощью препроцессора: то, что после stdafx.h и лежит в lib — дирректориях. На анализ у меня уходит 30 сек.
C>>Поспорили на счет того убирать ли инклуды из исходников (я — за то чтобы оставить). MSS>Не пофиг? время на споры только тратить.
Не пофиг
Во-первых, сразу нет возможности собрать не используя pch — например актуально для ночных билдов, чтобы требовать меньше места, а время сборки не так актуально.
Во-вторых, мне, чтобы использовать в тестовом проекте библиотеку-обертку над xmllib.dll нужно инклудить и obertka.h и xmllib.h — а если там еще какие сторонние типы или дефайны используются? — пойди потом гадай что и в какой очередности нужно инклудить стороннего, чтобы простой тестовый проект заработал...
В третьих, если я захочу собрать еще каким-то компилятором, то еще проблемы добавляются...
MSS>Ваш коллега меня просто поражает своей душевной простотой. Он вообще был в курсе, что проект надо собирать еще и под Linux? почему после внесения косметических правок, не влияющих на функционал, проект был брошен в не-строящемся состоянии?
Не знаю, вылетело наверно...Пару минорных проектов — начатый тест-engine, который как-обязателен, но все его отключают и без него все работает (кстати не собирался он именно по причине того, что были удалены системные инклуды...)
C>>Но больше всего меня поразило то, как была исправлена первая проблема – заголовки были возвращены в исходники, но обернуты #ifndef _Win32 MSS>Что это были за заголовки? специфичные для Линукса? тогда разумно.
Нет же, речь идет о сторонних библиотеках. т.е. например xmllib.h
C>>3. Решение изменить output директорию для поектов. Был введено два диска U: и V: на один – объектники, а на другой – бинарники. MSS>Мдаааа.... то есть в систему билдования жестко вшиты конкретные буквы томов? а на Линуксе это как будет работать?
у линукса отдельные файлы сборки
MSS>Вы оба хороши пользуетесь средствами билдования из Студии, а потом еще сбоку к ним ляпаете руками на соплях вписанные env vars и буквы томов.
Ну, с env vars — все ок: если есть, то используем абсолютный путь (как ниже с ramdisk), если нет, — то какой-то дефолтовый или где-то прописаный...
MSS>Правильно так: а) убедиться, что в студиевском файле проекта вообще нет абсолютных путей б) создать директорию на абы какой машине абы какой глубины как рука возьмет, единственное условие — на машине должна быть Студия в) поставить эту директорию в сорс-контроле как локальную г) взять с сорс-контрола все дерево д) запустить Студию дабл-кликом на файл проекта е) нажать там кнопку Build. Все.
Не кактит в случае если кто-то хочет "пооптимизировать" и использовать для объектников ramdisk (трое хотят) то не получится
C>>И опять делать не мне (наверно правильно новичкам не доверять). Вроде он сделал, но опять что-то не работает, и не особо разбираясь эти изменения откатили и теперь я не могу использовать две версии одновременно и обязвтельно должен иметь диски U и V MSS>Человек не исполнил команду лида, и создал вам проблемы в работе. Вы поставили лида в известность?
да видел все шеф, мое ощущение, что чел хотел показать что этот вариант работать не будет. такое ощущение, что на лида это повлияло...
C>>5. Организация авто-тестов в DLL. Видя что для юнит-тестов существует один проект (почти самописный NUnit), который будет линковать все остальные DLL, я высказал мнение, что «тест engine» не должен ни от чего зависеть, а тесты – сидеть в тех же библиотеках что и тестируемый код (но компилиться только опционально) увидел полное непонимание со стороны коллег
MSS>Правильно. При их подходе тестируется ровно тот же бинарь, что пойдет клиенту. Ваш подход имеет право на существование для тестирования каких-то интересных мест в пределах 1 бинаря, но для тестирования целых бинарей их подход лучше.
Ок, не со всем согласен, но здравого смысла тут хватает. Надо будет еше подумать.
C>>6. для проверки условий в тестах есть макрос типа Check(explanation_string, condition). Я сказал, что в коде таким пользоваться неудобно: во-первых, если в тесте десятки проверок, то придумывать каждый раз строку для объяснения – непрактично, во-вторых — если вначале строка, а справа — условие, то такой код читать неудобно. Написал свой макрос #define MyCheck(condition) Check(#condition, condition). В ответ – тоже непонимание типа «какждый кто приходит придумывает свои правила». Дыб опять.
MSS>Тоже они правы. Это лично вам неудобно так писать, а у них так принято.
по-моему нечитабельно или я не прав?
Check("Names are not equal", o.name()=="name");
Check("Number of elements in array incorrect", v.array().count()==5);
Check("Number of elements in second array incorrect", v.second_array().count()==6);
Check("Number of elements in First array of first object and Second array of second object are no equal", first.first_aray().count() == sec.second_array().count());
Здравствуйте, Sealcon190, Вы писали:
S>ИМХО ты не прав. S>Когда станешь прожект-лидером, тогда и меняй устоявшиеся порядки. На своем опыте убедился — то, что более эффективно по сути, может обернуться проблемами для проекта если люди не привыкли или не умеют так работать. Если каждый программер начинает давать советы по оптимизации труда, ничего кроме геморроя из этого не выходит.
Ок, согласен, но я не хочу работать с проектом, который требует жестко два диска на пустом месте и для того чтобы собрать версию стояшую у клиента и работать над новыми фичами в новой версии нужно делать бекап объектников или пересобирать все заново... Где релиз собирается в последнии день перед выпуском и проекты компилятся на 40% дольше возможного...
Что только два выхода — смириться или уволиться? И какой бы выбрал ты?
Здравствуйте, Cghjcbnm, Вы писали:
C>Ок, согласен, но я не хочу работать с проектом, который требует жестко два диска на пустом месте и для того чтобы собрать версию стояшую у клиента и работать над новыми фичами в новой версии нужно делать бекап объектников или пересобирать все заново... Где релиз собирается в последнии день перед выпуском и проекты компилятся на 40% дольше возможного...
C>Что только два выхода — смириться или уволиться? И какой бы выбрал ты?
Свобода или смерть!? =)
Всегда надо стремиться ХОТЕТЬ работать, а уволиться всегда успеешь.
На мой взгляд в данной ситуации (в смысле работыешь ты не давно (там), не тимлид) ты именно выпендриваешься =) , поработай, притрешься, будешь показывать правильный вектор развития (проект то ведь длинный) и люди за тобой потянуться, в данной ситуации на мой взгляд будешь требовать правильно работать (как ты считаешь ), финал будет один — выгонять в течении месяца-двух.
C>вот тут позвольте с вами и согласиться и нет. Как бы концептуально — я полностью за, но на практике вижу не первый раз позицию "у нас хорошие спецы и я им это поручил сделать".
Одно другого не исключает. Значит, _руководитель принял решение_ о том, что мини-решения на данном фронте работ принимает сам исполнитель.
C>То есть вы советуете не связываться с такими сслучаями — это же тоже не выход?
В профессиональном плане вы будете правы, в личностном — вы лезете не в свое дело, да и нарушаете негласно принятые в команде понятия о руководстве (в виде "исполнитель решает сам").
На раннем этапе работы в команде я бы (сейчас в 34 года) в чужие дела бы не лез. Но и ситуаций, когда чья-то халатность привела к тому, что проблемы на работе возникли уже у меня — тоже не допускал бы. Пусть каждый отвечает за свое.
Если команда действительно 100% дисфункциональна (что, в частности, означает профнепригодность лида) — то там карьеры не сделаешь и не вырастешь. В худшем случае — испортишь со всеми отношения, и "уйдут". В лучшем — сам уйдешь.
C>Здорово! Я почти враз поменял жизненные взгляды — уже не зря писал письмо
Немного оффтопика. Совки действительно считают, что все равны. Из гуманистического понятия "все мы люди" они делают вывод "все мы одинаковы". Из него логически следует, что в конфликте большинства с одиночкой всегда неправ одиночка.
Но дело в том, что люди НЕ одинаковы, и серое большинство может быть неправо в конфликте с талантливым одиночкой.
Но тут много всяких подтекстов. А может, одиночка ничем не более талантлив, все его мега-идеи уже приходили в голову и всем известны, но не воплощены в жизнь по неким причинам? А есть ли смысл переделывать работающее только потому, что можно сделать лучше? Дальше идут всякие "старый конь борозды не испортит" и прочее.
C>Позиция шефа — "а ты с аффтором разговаривал? ну давай еще пообсуждаем на форуме...". Или как-то по другому, что в итоге можно перевести "Я Петю больше знаю, я его варианту больше доверяю..."
Не говорит прямо. Возможно, слабак. Возможно, "афтар" ему уже сел на шею. Все это плохо, и минус не вам, а данной структуре.
C>Да согласен 100%! Ну не так просто попасть в такой проект, ведь такое достижимо только в новеньких проектах (например без паровоза 20-летних шедевров, хотя это другой случай)
Почему? что мешает регулярно билдовать 20летние шедевры? Вон ядро FreeBSD у нас с конца 70х тянется в значительной части, и ничего.
C>вот решил запустить релиз на второй неделе работы — не собрался...
Ну так а кому минус? за 2 недели явно продукт запускался как дебаг под средой раз эдак 500. И из них ни разу — релиз.
Как будто релизный билд есть что-то дополнительное и необязательное. На самом-то деле оно не так, разве не очевидно?
C>Разрешите оправдаться! C>Эта преальфа — не имеет никакой функцианальной полезности и выпущена скорее для высшего руководства
И что? майлстонный релиз есть майлстонный релиз. Вопросы того, для кого и зачем его выпускают — не вопросы девелопера. Даже высокооплачиваемого software engineer. Для этого ПМ есть в том или ином виде.
А вот поддержание кода всегда в качественном состоянии, чтобы качество никаких билдов не падало ниже какой-то планки — это вот задача девелопера.
C>На счет всего остального — шеф — один из нас 5-ти (знал прекрастно и сам пытался побороть) и дальше большой скачек в иерархии до непрограммистского начальства...
Угу. Знакомо.
Вполне возможно, что программирование для этой компании — вообще малозначимая игрушка. Вывод из всего этого — отдел могут подвергнуть резекции в любой момент. Так бывает.
MSS>>А что — у кого-то нет такого опыта? C>Представьте себе ни у одного из остальных (хотя и по возрасту и по опыту хор специалисты...)
Кстати, прекомпайл — это не Си++, в обычном Си тоже вполне применим.
C>Но проблема может быть то, что я в библиотеке A.dll включаю заголовок из B.dll который включает <xmllib.h>. (что в итоге и было в нашем случае). Узнать о том, что какой-то файл не включен можно только с помощью препроцессора: то, что после stdafx.h и лежит в lib — дирректориях. На анализ у меня уходит 30 сек.
Должна быть политика, что куда включать. Скажем, если A.DLL использует libxml как внутреннюю деталь реализации, то башки от libxml не стоит включать в интерфейсную башку от A.DLL.
Но если оная интерфейсная башка ссылается на типы и константы, которые объявлены в башках к libxml — тогда другое дело.
C>Во-первых, сразу нет возможности собрать не используя pch — например актуально для ночных билдов, чтобы требовать меньше места, а время сборки не так актуально.
Все равно с PCH быстрее. Дисковое место под билд в наше время вряд ли кого волнует.
C>Во-вторых, мне, чтобы использовать в тестовом проекте библиотеку-обертку над xmllib.dll нужно инклудить и obertka.h и xmllib.h — а если там еще какие сторонние типы или дефайны используются? — пойди потом гадай что и в какой очередности нужно инклудить стороннего, чтобы простой тестовый проект заработал...
Не добавляющие функционала обертки — как правило зло. Кроме того, можно воткнуть xmllib.h в общий заголовок stdafx.h или там precomp.h, после чего вообще забыть, куда ее нужно включать, куда нет. Тоже вариант.
C>Не знаю, вылетело наверно...Пару минорных проектов — начатый тест-engine, который как-обязателен, но все его отключают
Обязателен, но все отключают. Эффективность работы как у РФовской власти ельцинских времен.
C>Не кактит в случае если кто-то хочет "пооптимизировать" и использовать для объектников ramdisk
В нормальной команде это делается так:
— идея доводится до руководства.
— руководитель решает, заниматься ли ей, на каком моменте работ ей заниматься, и кто будет заниматься.
— после этого 1 человек (а не кто-то) — делает и так, и так, и замеряет время. Докладывает руководителю.
— руководитель принимает решение, будет ли использоваться рамдиск, причем _у всех_.
Я не верю в сильное ускорение работы с диском под NT или линуксом от использования рамдисков. У них кэширование очень хорошее.
Еще момент. Что мешает при большом ребилде всего проекта взять все исходники с сорс-контрола _на рамдиск_ и билдовать там? тоже вариант.
Сколько времени вообще делается полный ребилд самого большого бинаря в проекте? а всего проекта?
C>да видел все шеф, мое ощущение, что чел хотел показать что этот вариант работать не будет. такое ощущение, что на лида это повлияло...
Да, крепенько ему товарищ на шейку-то сел.
MSS>>Тоже они правы. Это лично вам неудобно так писать, а у них так принято.
C>по-моему нечитабельно или я не прав? C>
C>Check("Names are not equal", o.name()=="name");
C>Check("Number of elements in array incorrect", v.array().count()==5);
C>Check("Number of elements in second array incorrect", v.second_array().count()==6);
C>Check("Number of elements in First array of first object and Second array of second object are no equal", first.first_aray().count() == sec.second_array().count());
C>
Читабельно. Можно вообще только выражение и номер строки печатать. Все равно первое, что сделает девелопер, увидев такой ассерт — полезет в код, и от номера строки зачастую толку больше, чем от описания.
C>Что только два выхода — смириться или уволиться? И какой бы выбрал ты?
В тактическом плане — смириться, в стратегическом — это место работы не навсегда, и даже не надолго.
Тут, помимо прочего, еще интересная межличностная гниль вырисовывается. Похоже, малопрофессиональные, но давние сотрудники садятся на шею лиду как хотят.
У меня похожая ситуация. В команде работаю чуть больше месяца. Команда разработки софта не большая — 5 человек, а фирма занимается по большей части производством железа. У меня также как и у вас возникла куча вопросов, ответы на которые мне казались очевидны. Например:
1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?
2. Почему мы еще не перешли на Visual Studio 2005 а все еще юзаем 6.0???
2. А почему у вас нету Wiki, в качестве базы знаний?
3. А почему вы не используете Jira в качестве багтрэкинга? Ведь по опыту я знаю что это перфект!
4. Вопрос тимлиду: Почему вы разрешаете в VSS комитить некомпилябельный код??? Этот вопрос был результатом 2 часового спора с девелопером который закомител код, и даже не удосужился его скомпилять перед этим.
и т.д.
Но я отношусь к этому терпеливо. Если я действительно прав, тогда рано или поздно это всплывет и у меня будет возможность сказать: "Ну я же вам постоянно об этом говорю, за что боролись на то и напоролись!" Но если потребность в моих предложениях так и не возникнет, то мне самому есть над чем задуматься, ведь мой опыт не был основан на реальной практической потребности. До этого я работал в большой софтверной компании где все уже было настроено и работало, а я только восхищался и говорил "Как все классно сделано!". Теперь я прихожу в другую компанию и начинаю "требовать", чтобы они делали все так как это делалось в моей предыдущей конторе. Я считаю, что так поступать нельзя. Наоборот я радуюсь что у меня есть возможность реально ощутить потребность в моих предложениях и когда это произойдет у меня будет достаточно аргументов чтобы убедить руководство делать именно так как я предлагаю.
Но есть вещи на которые я могу привести аргументы в любой момент, например "Codestyle необходим, как и его соблюдение всеми членами команды!", и не одному тимлиду неудастся отвертется
X>У меня похожая ситуация. В команде работаю чуть больше месяца. Команда разработки софта не большая — 5 человек, а фирма занимается по большей части производством железа. У меня также как и у вас возникла куча вопросов, ответы на которые мне казались очевидны. Например:
Эх, молодежь, все то вы думаете что самые умные. Ничего личного, это я по доброму
X>1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?
Простите, а чем CVS лучше VSS? Чем VSS? Не вижу никаких преимуществ (для VSS есть и клиенты для Linux, лично использовал SourceOffSite). Сейчас использую CVS — в чем-то система не дотягивает до VSS (в CVS насколько я знаю, нет полноценного лока).
X>2. Почему мы еще не перешли на Visual Studio 2005 а все еще юзаем 6.0???
Потому, что если VC 6.0 прекрасно справляется с поставленной задачей, то нет причин переходить на VS2005.
X>2. А почему у вас нету Wiki, в качестве базы знаний?
Потому, что это "нафиг" никому не нужно.
X>3. А почему вы не используете Jira в качестве багтрэкинга? Ведь по опыту я знаю что это перфект!
Потому, что на Ваше мнение всем ... пока Ваш вес внутри команды не поднимется до определенного уровня.
X>4. Вопрос тимлиду: Почему вы разрешаете в VSS комитить некомпилябельный код??? Этот вопрос был результатом 2 часового спора с девелопером который закомител код, и даже не удосужился его скомпилять перед этим. X>и т.д.
Это зависит от политики автоматизации билдов. Если будет ночной автобилд и всем наутро придет письмо, что билд повалил Вася Пупкин, то это быстро излечит его от таких "фокусов". Я часто коммичу "некомпиляемый" код — предварительно добавив #if 0/ #endif
X>Но я отношусь к этому терпеливо. Если я действительно прав, тогда рано или поздно это всплывет и у меня будет возможность сказать: "Ну я же вам постоянно об этом говорю, за что боролись на то и напоролись!" Но если потребность в моих предложениях так и не возникнет, то мне самому есть над чем задуматься, ведь мой опыт не был основан на реальной практической потребности. До этого я работал в большой софтверной компании где все уже было настроено и работало, а я только восхищался и говорил "Как все классно сделано!". Теперь я прихожу в другую компанию и начинаю "требовать", чтобы они делали все так как это делалось в моей предыдущей конторе. Я считаю, что так поступать нельзя. Наоборот я радуюсь что у меня есть возможность реально ощутить потребность в моих предложениях и когда это произойдет у меня будет достаточно аргументов чтобы убедить руководство делать именно так как я предлагаю.
Вот это правильно
X>Но есть вещи на которые я могу привести аргументы в любой момент, например "Codestyle необходим, как и его соблюдение всеми членами команды!", и не одному тимлиду неудастся отвертется
Логично. Только случаев его полного соблюдения я никогда не видел.
X>1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?
Вы точно уверены, что хотите на ходу посреди проекта менять сорс-контрол?
Понятие "все нормальные конторы" выдает узость кругозора. Например — если контора пользуется SourceOffSite, она не нормальная? а если она пользуется TFS? а если она пользуется Perforce?
Не в сорс-контроле дело тут, а в руках и мозгах. Можно и на VSS работать на порядок качественнее, чем обсуждаемая команда. А можно и на TFS запутаться.
X>2. Почему мы еще не перешли на Visual Studio 2005 а все еще юзаем 6.0???
Мдаа... расскажите нам (аудитории форума), в чем смысл версио-мании и гонки за последними версиями, особенно в условиях, когда речь о большом объеме старого кода.
X>2. А почему у вас нету Wiki, в качестве базы знаний?
На 5 человек?
X>3. А почему вы не используете Jira в качестве багтрэкинга? Ведь по опыту я знаю что это перфект!
Один из ответов "а потому, что мы использует Мантис", или "потому, что мы используем багтрекер от SourceOffSite".
X>4. Вопрос тимлиду: Почему вы разрешаете в VSS комитить некомпилябельный код???
Вот это — дело. Тут скорее вопрос — "почему вообще терпите такого слабого девелопера".
X>Но я отношусь к этому терпеливо. Если я действительно прав, тогда рано или поздно это всплывет и у меня будет возможность сказать: "Ну я же вам постоянно об этом говорю, за что боролись на то и напоролись!" Но если потребность в моих предложениях так и не возникнет, то мне самому есть над чем задуматься, ведь мой опыт не был основан на реальной практической потребности. До этого я работал в большой софтверной компании где все уже было настроено и работало, а я только восхищался и говорил "Как все классно сделано!". Теперь я прихожу в другую компанию и начинаю "требовать", чтобы они делали все так как это делалось в моей предыдущей конторе. Я считаю, что так поступать нельзя. Наоборот я радуюсь что у меня есть возможность реально ощутить потребность в моих предложениях и когда это произойдет у меня будет достаточно аргументов чтобы убедить руководство делать именно так как я предлагаю.
+1.
X>Но есть вещи на которые я могу привести аргументы в любой момент, например "Codestyle необходим, как и его соблюдение всеми членами команды!", и не одному тимлиду неудастся отвертется
На моей бывшей работе codestyle вырабатывали 4 лида целый рабочий день минимум (или два, не помню уж), и консенсусу — кроме совсем основополагающих вещей — не пришли.
Больше похоже что обычные рабочие ситуации которых из которых и состоит работа вы проецируете на каеи то свои мании. Это естествено что кто то чего то не знает, а другой знает.
Здравствуйте, Cghjcbnm, Вы писали:
C>Ок, согласен, но я не хочу работать с проектом, который требует жестко два диска на пустом месте и для того чтобы собрать версию стояшую у клиента и работать над новыми фичами в новой версии нужно делать бекап объектников или пересобирать все заново... Где релиз собирается в последнии день перед выпуском и проекты компилятся на 40% дольше возможного...
C>Что только два выхода — смириться или уволиться? И какой бы выбрал ты?
Если проект мне реально интересен, а атмосфера в команде здоровая, то никакие два диска на пустом месте и другие сопутствующие неудобства погоды не делают. Тем более что по мере зарабатывания авторитета ситуацию можно ненавязчиво менять.
X>>У меня похожая ситуация. В команде работаю чуть больше месяца. Команда разработки софта не большая — 5 человек, а фирма занимается по большей части производством железа. У меня также как и у вас возникла куча вопросов, ответы на которые мне казались очевидны. Например:
AZ>Эх, молодежь, все то вы думаете что самые умные. Ничего личного, это я по доброму
X>>1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?
AZ>Простите, а чем CVS лучше VSS? Чем VSS? Не вижу никаких преимуществ (для VSS есть и клиенты для Linux, лично использовал SourceOffSite). Сейчас использую CVS — в чем-то система не дотягивает до VSS (в CVS насколько я знаю, нет полноценного лока).
В CVS идеология работы немного отличается. Например полноценный лок там не нужен по идеологическим причинам
X>>2. Почему мы еще не перешли на Visual Studio 2005 а все еще юзаем 6.0???
AZ>Потому, что если VC 6.0 прекрасно справляется с поставленной задачей, то нет причин переходить на VS2005.
С этим не поспоришь.
X>>2. А почему у вас нету Wiki, в качестве базы знаний?
AZ>Потому, что это "нафиг" никому не нужно.
Но всетаки я поставил, и оказалось что это очень полезная штука Например теперь всякую мелоч которая возникает в голове разработчики и тестеры заносят туда. Например идеи, предложения, полезные ссылки и т.д. Такое вот внутриконторное социальное комьюнити или лучше — общая доска куда можно писать. Теперь со стороны начальства возникают пожелания туда еще и все важные документы переносить, а также чтобы система автоматического тестирования туда заносила результаты.
X>>3. А почему вы не используете Jira в качестве багтрэкинга? Ведь по опыту я знаю что это перфект!
AZ>Потому, что на Ваше мнение всем ... пока Ваш вес внутри команды не поднимется до определенного уровня.
С этим тоже не поспоришь.
X>>4. Вопрос тимлиду: Почему вы разрешаете в VSS комитить некомпилябельный код??? Этот вопрос был результатом 2 часового спора с девелопером который закомител код, и даже не удосужился его скомпилять перед этим. X>>и т.д.
AZ>Это зависит от политики автоматизации билдов. Если будет ночной автобилд и всем наутро придет письмо, что билд повалил Вася Пупкин, то это быстро излечит его от таких "фокусов". Я часто коммичу "некомпиляемый" код — предварительно добавив #if 0/ #endif
На предыдущих местах работы (а их было 3), везде была аксиома "В системе контроля версий хранится только компилируемый код — не обязательно работающий" И этому есть достаточно весомые объяснения: к примеру, несколько дней тому назад, у нас в конторе два программиста чуть не подрались из-за того что один закомител код, который предварительно не проверил
В одной большой компании где я работал до сих пор, коммитами занимался вобще отдельный человек — коммитер, а разработчики не имели доступа на коммит.
X>>Но есть вещи на которые я могу привести аргументы в любой момент, например "Codestyle необходим, как и его соблюдение всеми членами команды!", и не одному тимлиду неудастся отвертется
AZ>Логично. Только случаев его полного соблюдения я никогда не видел.
А я видел, когда "коммитер" мне постоянно отпинывал обратно мои коммиты и говорил что не будет вносить мой код в CVS пока я не выровняю строки по 80 символов
X>В CVS идеология работы немного отличается. Например полноценный лок там не нужен по идеологическим причинам
Было бы интересно, если бы раскрыли идеологию CVS. CVS меня не напрягает, более того перестал пользоваться GUI практически — лочить не надо, а коммитить из командной строки хорошо.
AZ>>Логично. Только случаев его полного соблюдения я никогда не видел.
X>А я видел, когда "коммитер" мне постоянно отпинывал обратно мои коммиты и говорил что не будет вносить мой код в CVS пока я не выровняю строки по 80 символов
80 символов — это лишь малая часть Coding Standards. У нас были десятки правил, только их никто не проверял, потому как автоматической тулзы не было, а ручками это делать никому не хотелось
Здравствуйте, Maxim S. Shatskih, Вы писали:
X>>1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?
MSS>Вы точно уверены, что хотите на ходу посреди проекта менять сорс-контрол?
Нет в этом я уже совсем не уверен. Но если проекту 10 лет, то всетаки когдато нужно это делать?
MSS>Понятие "все нормальные конторы" выдает узость кругозора. Например — если контора пользуется SourceOffSite, она не нормальная? а если она пользуется TFS? а если она пользуется Perforce?
MSS>Не в сорс-контроле дело тут, а в руках и мозгах. Можно и на VSS работать на порядок качественнее, чем обсуждаемая команда. А можно и на TFS запутаться.
Согласен.
X>>2. Почему мы еще не перешли на Visual Studio 2005 а все еще юзаем 6.0???
MSS>Мдаа... расскажите нам (аудитории форума), в чем смысл версио-мании и гонки за последними версиями, особенно в условиях, когда речь о большом объеме старого кода.
Ну смысл наверное в том, что время идет, средства меняются в лучшую сторону, новые команды (конкуренты) осваивают новые средства разработки, и скорее всего в этом имеют преимущество перед теми кто уже 10 лет ковыряет старое и боиться переходить на новое. Слово боязнь тут ключевое. Именно боязнь перед всем новым сейчас тормозит развитие в конторе. Когда тим лид говорит не нужно использовать механизм исключений в Си++ потомучто сам с ним не знаком и часть разработчиков тоже — это тоже самое. Такая же боязнь и перед MSVC 2005.
Но всетаки переход запланирован. Причиной оказалось то, что майкрософт больше не поддерживает 6.0
X>>2. А почему у вас нету Wiki, в качестве базы знаний?
MSS>На 5 человек?
Сегодня уже 5 человек путаются и не могут мне объяснить как должно работать приложение. А когда по вашему нужно вводить базу знаний в конторе?
Я не считаю что именно wiki должно быть инструментом, можно и доки писать. Но разработчиков которые привыкли только писать на форумах, проще попросить записывать в wiki чем писать документы и еще кудато выкладывать.
X>>3. А почему вы не используете Jira в качестве багтрэкинга? Ведь по опыту я знаю что это перфект!
MSS>Один из ответов "а потому, что мы использует Мантис", или "потому, что мы используем багтрекер от SourceOffSite".
Хорошо вам. А вот мы используем какую то табличку завязанную на Access
X>>4. Вопрос тимлиду: Почему вы разрешаете в VSS комитить некомпилябельный код???
MSS>Вот это — дело. Тут скорее вопрос — "почему вообще терпите такого слабого девелопера".
Хороший вопрос. Ответ (как мне кажется): потомучто к старому девелоперу привыкли как и к 6.0-й студии а нового видимо страшно брать, а то начнет еще революционные идеи толкать вместо работы
X>>Но есть вещи на которые я могу привести аргументы в любой момент, например "Codestyle необходим, как и его соблюдение всеми членами команды!", и не одному тимлиду неудастся отвертется
MSS>На моей бывшей работе codestyle вырабатывали 4 лида целый рабочий день минимум (или два, не помню уж), и консенсусу — кроме совсем основополагающих вещей — не пришли.
Поэтому я предлагаю взять готовый кодестайл и принять его
X>Ну смысл наверное в том, что время идет, средства меняются в лучшую сторону, новые команды (конкуренты) осваивают новые средства разработки, и скорее всего в этом имеют преимущество перед теми кто уже 10 лет ковыряет старое и боиться переходить на новое.
Все это называется "словеса из глянцевых журналов". Темпы развития ИТ сейчас сильно упали по сравнению с 90ми годами, это раз. С 2000ного года появилась всего одна серьезная новая технология — .NET, все остальное было уже в 2000.
Ну и, понятно, если проект не использует .NET, то толком его технологическая база не изменилась со времен этого самого MSVC 6.
X>Слово боязнь тут ключевое.
Скорее "нежелание гимора", чем боязнь.
X>Именно боязнь перед всем новым сейчас тормозит развитие в конторе.
В обсуждаемой конторе бардак, и она не может нормально работать, перейдут они на новое или нет.
Уж что-что, а версия тулов, которыми пользуется девелопер, вообще дело третьестепенное.
X>Когда тим лид говорит не нужно использовать механизм исключений в Си++ потомучто сам с ним не знаком и часть разработчиков тоже — это тоже самое.
С++ exceptions имеет чудовищные недостатки, которые очевидны как раз тем, кто знает этот механизм хорошо. Он ухудшает понятность кода. Запрещать его совсем? смотря где. В особо ответственном системном или алгоритмическом коде — да. В чем-то вроде UI — нет.
Кстати, при чем тут C++ exceptions, которые появились в начале 90х, и "новое"?
X>Сегодня уже 5 человек путаются и не могут мне объяснить как должно работать приложение.
Так это проблемы _в этих человеках_, а не в наличии или отсутствии базы знаний.
MSS>>Один из ответов "а потому, что мы использует Мантис", или "потому, что мы используем багтрекер от SourceOffSite". X>Хорошо вам. А вот мы используем какую то табличку завязанную на Access
Если правильная табличка — то все у вас хорошо. Хотя я предпочитаю интранетовские багтрекеры, пусть и на PHP/MySQL написанные.
X>>>4. Вопрос тимлиду: Почему вы разрешаете в VSS комитить некомпилябельный код???
MSS>>Вот это — дело. Тут скорее вопрос — "почему вообще терпите такого слабого девелопера". X>Хороший вопрос. Ответ (как мне кажется): потомучто к старому девелоперу привыкли как и к 6.0-й студии а нового видимо страшно брать, а то начнет еще революционные идеи толкать вместо работы
Боязнь нового а) в значительной степени преувеличена б) в этой конторе не главное. Главное — профессиональная слабость персонала.
MSS>>На моей бывшей работе codestyle вырабатывали 4 лида целый рабочий день минимум (или два, не помню уж), и консенсусу — кроме совсем основополагающих вещей — не пришли. X>Поэтому я предлагаю взять готовый кодестайл и принять его
Тогда лиды потратят 2 дня на то, чтобы выяснить, какой именно готовый codestyle они хотят.
В реальной жизни жесткие и длинные требования к codestyle соблюдать не удается практически никому. Эдакие размягченные и краткие требования — это да, соблюдают.
Кроме того, хорош _любой_ codestyle, если он читаем. Цель введения codestyle — вовсе не унификация, а повышение читаемости кода.
X>А я видел, когда "коммитер" мне постоянно отпинывал обратно мои коммиты и говорил что не будет вносить мой код в CVS пока я не выровняю строки по 80 символов
Ну это очень важно. Например, люди хотят, чтобы код читался на 800x600.
Здравствуйте, Cghjcbnm, Вы писали:
C>Может ли кто-то сказать: я выпендриваюсь или мои волосы не зря дыбом становятся? (То есть, то, что волосы дыбом становятся при удивлении — не проблема. Вопрос — есть ли причина для удивления?)
Если не можешь убедить их, что твоя точка зрения верна, то:
а) Нужно развиваться в этом направлении дальше, это хорошо, что видишь что и как можно улучшить.
б) Команда не вменяемая (это бывает довольно редко), есть большая вероятноть что продукт завалят, и ты на это никак не можешь повлиять — надо уходить.
Здравствуйте, Cghjcbnm, Вы писали:
C>Пришел в интересную компанию в небольшую команду (5 чел). C>Проект интересный, сложный, команда распределенная...
Как мне кажется, если человек не наивный студент, то о подобных вещах (бардак в разработке, слабая подготовка некоторых людей в команде и т.д.) он догадается уже на собеседовании. Вы лично о чём думали на собеседовании — чтобы Вас взяли? А нужно было смотреть, что за команда, что за люди. В идеале позадавать технические вопросы собеседователю Чем меньше наивности в отношении работодателя и проектов, тем лучше.
Насчёт увольняться или нет. Если Вы на испытательном сроке и есть(легко могут быть найдены) другие альтернативы, то думаю, стоит подумать об увольнении. Если с первых моментов работы уже такой настрой, дальше, имхо, лучше не станет.
X>>1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?
AZ>Простите, а чем CVS лучше VSS? Чем VSS? Не вижу никаких преимуществ (для VSS есть и клиенты для Linux, лично использовал SourceOffSite). Сейчас использую CVS — в чем-то система не дотягивает до VSS (в CVS насколько я знаю, нет полноценного лока).
CVS не использовал. VSS и Subversion могу сравнить:
VSS хуже тем, что она не транзакционная, т.е. при комите 20 файлов вполне может закомитить 10, потом сказать — всё, сеть пропала, или прочитать чего не могу — и получится что в репозитории лежит версия, которая не комплируется (в лучшем случае), а в худшем — компилируется, но работает не правильно. Если кто-то берет свежую версию в момент моего комита, тоже может получить часть моих изменений, а часть придется "докачивать" потом, когда поймет что-то не так.
Отсутствие понятния "ревизия" мешает при анализе изменений — т.е. нет простого способа глянуть все файлы, которые были включены в комит вместе с каким-либо изменением. Существующие label не особо помогают, потому что их надо накладывать отдельно, и на весь проект.
VSS на большой базе (от гига) — постоянно слетала, приходилось запускать утилиту починки.
Работа с бранчами в VSS после Subbversion иначе как "полный капец" не назовешь.
При этом обратите внимание, я не приводил никаких аргументов вроде удобства, скорости, доступность через веб и пр. — только исключительно критические недостатки, которые серьезно влияют на работу над проектом.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>С++ exceptions имеет чудовищные недостатки, которые очевидны как раз тем, кто знает этот механизм хорошо. Он ухудшает понятность кода. Запрещать его совсем? смотря где. В особо ответственном системном или алгоритмическом коде — да. В чем-то вроде UI — нет.
Зато код в котором не используются исключения, а обработка ошибок ведется на абум имеет гораздо больше чудовищных недостатков, которые я сейчас наблюдаю в конторе. А понятность кода это дело спорное, для меня гораздо понятнее видеть логичное разделение кода на try catch блоки и сразу видно какой код обрабатывается а какой нет. Возьмем другую альтернативу обработка кодов ошибок: код превращается в сплошную кашу из if блоков и к томуже чудовищный недостаток — легко забыть проверить код возврата.
Пардон за флем
MSS>Кстати, при чем тут C++ exceptions, которые появились в начале 90х, и "новое"?
Для когото и исключения в Си++ новость Но скорее тут правильнее сказать "гемор" а не "новое".
MSS>Боязнь нового а) в значительной степени преувеличена б) в этой конторе не главное. Главное — профессиональная слабость персонала.
Слабость персонала это проблема скорее глобальная чем в этой конторе. И с этим надо както жить. Полагаю это одна из причин создание новых средств разработки.
Здравствуйте, xfruit, Вы писали:
X>Но всетаки я поставил, и оказалось что это очень полезная штука Например теперь всякую мелоч которая возникает в голове разработчики и тестеры заносят туда. Например идеи, предложения, полезные ссылки и т.д. Такое вот внутриконторное социальное комьюнити или лучше — общая доска куда можно писать. Теперь со стороны начальства возникают пожелания туда еще и все важные документы переносить, а также чтобы система автоматического тестирования туда заносила результаты.
И я тоже хочу WIKI... Что ставить надо? Откуда слить?
Здравствуйте, trophim, Вы писали:
T>Здравствуйте, xfruit, Вы писали:
X>>Но всетаки я поставил, и оказалось что это очень полезная штука Например теперь всякую мелоч которая возникает в голове разработчики и тестеры заносят туда. Например идеи, предложения, полезные ссылки и т.д. Такое вот внутриконторное социальное комьюнити или лучше — общая доска куда можно писать. Теперь со стороны начальства возникают пожелания туда еще и все важные документы переносить, а также чтобы система автоматического тестирования туда заносила результаты.
T>И я тоже хочу WIKI... Что ставить надо? Откуда слить?
Здравствуйте, AntZ, Вы писали:
X>>2. Почему мы еще не перешли на Visual Studio 2005 а все еще юзаем 6.0???
AZ>Потому, что если VC 6.0 прекрасно справляется с поставленной задачей, то нет причин переходить на VS2005.
Есть, есть
И отговорки типа "нафиг не надо", это всего лишь способ самоуспокоения
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
MSS>Все это называется "словеса из глянцевых журналов". Темпы развития ИТ сейчас сильно упали по сравнению с 90ми годами, это раз. С 2000ного года появилась всего одна серьезная новая технология — .NET, все остальное было уже в 2000.
MSS>Ну и, понятно, если проект не использует .NET, то толком его технологическая база не изменилась со времен этого самого MSVC 6.
MSVC 6,0 не поддерживает стандарт, хреново работает с шаблонами. Но меня недавно вообще добила в std::string нет clear().
В итоге я не могу использовать язык на полную мощность . Да и борьба с глюками компилятора, занятие не из приятных.
MSS>Уж что-что, а версия тулов, которыми пользуется девелопер, вообще дело третьестепенное.
X>>Когда тим лид говорит не нужно использовать механизм исключений в Си++ потомучто сам с ним не знаком и часть разработчиков тоже — это тоже самое.
MSS>С++ exceptions имеет чудовищные недостатки, которые очевидны как раз тем, кто знает этот механизм хорошо. Он ухудшает понятность кода. Запрещать его совсем? смотря где. В особо ответственном системном или алгоритмическом коде — да. В чем-то вроде UI — нет.
Хе... Писать устойчивый к исключениям код безусловно сложнее, т.к. требует большей внимательности и опыта. Понятность кода эксепшены скорее улучшают, т.к. уходят все эти if'ы, которые захламляют код. Мало того, почему же эта "чудовищная" концепция перешла в Java и C#, да еще в кучу языков?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
DC>MSVC 6,0 не поддерживает стандарт, хреново работает с шаблонами. Но меня недавно вообще добила в std::string нет clear().
DC>В итоге я не могу использовать язык на полную мощность . Да и борьба с глюками компилятора, занятие не из приятных.
Великое развитие технологий за 10 лет развития микрософтного компилятора Си++ туда добавили std::string::clear() и исправили мелкие баги да, это новая эпоха ИТ, безусловно
DC>Хе... Писать устойчивый к исключениям код безусловно сложнее, т.к. требует большей внимательности и опыта. Понятность кода эксепшены скорее улучшают, т.к. уходят все эти if'ы, которые захламляют код. Мало того, почему же эта "чудовищная" концепция перешла в Java и C#, да еще в кучу языков?
Почитайте, что системные программисты из Микрософта пишут про эту фичу. Ларри Остерман, например.
Если обобщить все, что по этому поводу написано и сторонниками, и противниками — то получается примерно вот что.
Когда этот механизм присутствует в платформе сверху донизу, как в Джаве и Шарпе — то он хорош. Претензии есть только к деталям типа омерзительной фичи Джавы в виде обязательной спецификации throws, которая приводит к написанию оберток, перекладывающих один вид exceptionов в другой Exception contracts реально мешают работать, а толк от них — не более чем в умозрении архитекторов, мечтающих о башнях из слоновой кости.
Но когда этот механизм не есть натуральная часть платформы, а есть нечто данное отдельно как фича языка, как в Си++ — то гимора не избежать. Как минимум нужно все функции Win32 обернуть в обертки, которые бросают exception в случае облома. Все локи обернуть в классы, чтобы отдавались в случае, если пролетел exception.
Если и неизлечимые проблемы этого механизма, в любом языке. Пример: есть код, под локом выполняет внесение атомарных изменений в сложные данные. По ходу вызывает 2 функции. И вот у нас вылетел откуда-то exception. Надо не просто лок отдать, а и уже сделанные изменения данных откатить в старое целостное состояние. В ядрах ОС требования по надежности такого уровня — норма.
Фишка в том, что в блоке catch() неизвестно, из какого из двух внутренних вызовов вылетел exception, и потому неизвестно, сколько откатывать. Единственный выход — обернуть каждый вызов в try/catch и _по-старому обрабатывать возврат кода ошибки_.
Это очень большая проблема frame-based exceptions — в обработчике неизвестен точный момент их возникновения, а значит — точное состояние системы на момент возникновения, что создает сложности с откатом. Именно на это обращал внимание Остерман.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Но когда этот механизм не есть натуральная часть платформы, а есть нечто данное отдельно как фича языка, как в Си++ — то гимора не избежать. Как минимум нужно все функции Win32 обернуть в обертки, которые бросают exception в случае облома. Все локи обернуть в классы, чтобы отдавались в случае, если пролетел exception.
И это замечательно , именно это и делают программисты которые хотят избежать гемора с Win32 и т.п.
MSS>Если и неизлечимые проблемы этого механизма, в любом языке. Пример: есть код, под локом выполняет внесение атомарных изменений в сложные данные. По ходу вызывает 2 функции. И вот у нас вылетел откуда-то exception. Надо не просто лок отдать, а и уже сделанные изменения данных откатить в старое целостное состояние. В ядрах ОС требования по надежности такого уровня — норма.
Проблемы не сижу, вижу тольтко некоректное использование механизма.
MSS>Фишка в том, что в блоке catch() неизвестно, из какого из двух внутренних вызовов вылетел exception, и потому неизвестно, сколько откатывать. Единственный выход — обернуть каждый вызов в try/catch и _по-старому обрабатывать возврат кода ошибки_.
Ну что сказать кроме того что выше. Для сравнения можно одну и туже функциональность писать с исключениями и без. Я это неоднократно делал.
MSS>Это очень большая проблема frame-based exceptions — в обработчике неизвестен точный момент их возникновения, а значит — точное состояние системы на момент возникновения, что создает сложности с откатом. Именно на это обращал внимание Остерман.
А как эти сложности решаются без исключений ?
Здравствуйте, Maxim S. Shatskih, Вы писали:
DC>>Хе... Писать устойчивый к исключениям код безусловно сложнее,
Отказоустойчивый код вообще сложно писать
Самый кайф ловишь когда пишешь отказоустойчивый многопоточный код.
MSS>Почитайте, что системные программисты из Микрософта пишут про эту фичу. Ларри Остерман, например.
Системные, это те которые пишут код там, где и механизма исключений как такового нет ?
MSS>Но когда этот механизм не есть натуральная часть платформы, а есть нечто данное отдельно как фича языка, как в Си++ — то гимора не избежать. Как минимум нужно все функции Win32 обернуть в обертки, которые бросают exception в случае облома. Все локи обернуть в классы, чтобы отдавались в случае, если пролетел exception.
Ну ведь как-то живут с этими "накладными" расходами
MSS>Если и неизлечимые проблемы этого механизма, в любом языке. Пример: есть код, под локом выполняет внесение атомарных изменений в сложные данные. По ходу вызывает 2 функции. И вот у нас вылетел откуда-то exception. Надо не просто лок отдать, а и уже сделанные изменения данных откатить в старое целостное состояние. В ядрах ОС требования по надежности такого уровня — норма.
По-моему — это нормальные требования к любой более менее сложной программе/компоненте.
MSS>Фишка в том, что в блоке catch() неизвестно, из какого из двух внутренних вызовов вылетел exception, и потому неизвестно, сколько откатывать. Единственный выход — обернуть каждый вызов в try/catch и _по-старому обрабатывать возврат кода ошибки_.
Иногда делают именно так.
Иногда — в процессе модификации данных формируется список с командами для отката. Список очищается при успешном завершении модификации. В случае исключения он задействуется для возврата в исходное состояние.
И наконец. В тупую копируем исходные данные, модифицируем копию и, если все прошло успешно, копия замещает исходные данные. Мой любимый способ для организации транзакционных изменений в более менее нетривиальных контейнерах данных.
Наверное есть еще алгоритмы, типа версионности из Interbase/Firebird.
MSS>Это очень большая проблема frame-based exceptions — в обработчике неизвестен точный момент их возникновения, а значит — точное состояние системы на момент возникновения, что создает сложности с откатом. Именно на это обращал внимание Остерман.
Я может туплю, но по-моему без исключений откаты организовать еще сложнее. Я конечно ядра OC не писал, но хорошо помню упрощение в реализации отказоустойчивого кода, когда перешел на использование исключения.
В однослойных, максимум двухслойных, моделях, без исключений еще жить как-то можно. Но когда появляется третий слой, а второй к тому же является обобщенным кодом (шаблоном, настраиваемым тем самым третим слоем), то без наличия механизма исключений можно вешаться. Я поначалу пытался вешаться на шею своей подруге, но она мне сказала — "животное, используй исключения и отстань от меня"
В целом, не понятно в чем собственно выражаются "чудовищные недостатки механизма C++" с точки зрения "хорошо знающих его механизм"
Проблемы с откатами к исходному состоянию — решаются.
Проблемы с границами "разнородных" модулей — тоже (нужна некая общая платформа, типа COM). Все точки входа в модуль (типа DLL с COM-объектами) обертываются в try{}catch.
Проблемы с возобновлением ... ну не могут они этого, да и хрен с ним, с возобновлением. Все это тоже преодолевается.
Ухудшение читабельности? Уж извините — это бред.
Ограничения catch-а преодолеваются с помощью вот этой
фичи. Я до сих пор в шоке, почему я сам до этого не допер
Есть еще что-то?
Вообще странно когда MVP сетует на какие-то проблемы с исключениями. Он должен говорить так — "а те казлы, которые думают что исключения придумали и используют исключительно ламеры, пусть возвращаются к себе, в горы"
Или это ты так, нас, ламеров, разводишь? Гы.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Maxim S. Shatskih, Вы писали:
DC>>MSVC 6,0 не поддерживает стандарт, хреново работает с шаблонами. Но меня недавно вообще добила в std::string нет clear().
DC>>В итоге я не могу использовать язык на полную мощность . Да и борьба с глюками компилятора, занятие не из приятных.
MSS>Великое развитие технологий за 10 лет развития микрософтного компилятора Си++ туда добавили std::string::clear() и исправили мелкие баги да, это новая эпоха ИТ, безусловно
Ты это к чему? Я про новые эпохи ничего не говорил, я тебе про конкретные кривости, конкретного компилятора.
DC>>Хе... Писать устойчивый к исключениям код безусловно сложнее, т.к. требует большей внимательности и опыта. Понятность кода эксепшены скорее улучшают, т.к. уходят все эти if'ы, которые захламляют код. Мало того, почему же эта "чудовищная" концепция перешла в Java и C#, да еще в кучу языков?
MSS>Почитайте, что системные программисты из Микрософта пишут про эту фичу. Ларри Остерман, например.
MSS>Если обобщить все, что по этому поводу написано и сторонниками, и противниками — то получается примерно вот что.
MSS>Когда этот механизм присутствует в платформе сверху донизу, как в Джаве и Шарпе — то он хорош. Претензии есть только к деталям типа омерзительной фичи Джавы в виде обязательной спецификации throws, которая приводит к написанию оберток, перекладывающих один вид exceptionов в другой Exception contracts реально мешают работать, а толк от них — не более чем в умозрении архитекторов, мечтающих о башнях из слоновой кости.
С тем, что спецификация эксепшенов — это зло я полностью согласен, ибо ничего не дает, а требует много.
MSS>Но когда этот механизм не есть натуральная часть платформы, а есть нечто данное отдельно как фича языка, как в Си++ — то гимора не избежать. Как минимум нужно все функции Win32 обернуть в обертки, которые бросают exception в случае облома. Все локи обернуть в классы, чтобы отдавались в случае, если пролетел exception.
О RAII слышал? Так вот оно для этого. Но тут собственно никто не виноват, что ядро Винды написано на С, а он ексепшены не поддерживает. Это претензия не к механизму.
MSS>Если и неизлечимые проблемы этого механизма, в любом языке. Пример: есть код, под локом выполняет внесение атомарных изменений в сложные данные. По ходу вызывает 2 функции. И вот у нас вылетел откуда-то exception. Надо не просто лок отдать, а и уже сделанные изменения данных откатить в старое целостное состояние. В ядрах ОС требования по надежности такого уровня — норма.
Тут нужно транзакционность сделать — это все решаемая проблема, делаем изменения сначала в каком-то "сандбоксе", а когда все операции прошли накатываем целиком.
MSS>Фишка в том, что в блоке catch() неизвестно, из какого из двух внутренних вызовов вылетел exception, и потому неизвестно, сколько откатывать. Единственный выход — обернуть каждый вызов в try/catch и _по-старому обрабатывать возврат кода ошибки_.
Откатывать все Причем не catch должен откатывать а деструкторы. В catch'e можно проверить инварианты, и если они нормальные перекрестясь продолжать работу.
MSS>Это очень большая проблема frame-based exceptions — в обработчике неизвестен точный момент их возникновения, а значит — точное состояние системы на момент возникновения, что создает сложности с откатом. Именно на это обращал внимание Остерман.
Поддержка кода написанного с проверной кода возврата значительно сложнее в поддержке. На уровне ядра ОСи когда надо вернуть в исходное состояние процесс после эксепшена, гораздо проще его убить и запустить заново. Просто архитектура ОС у нас монолитная, а не миркоядерная.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
MSS>>Почитайте, что системные программисты из Микрософта пишут про эту фичу. Ларри Остерман, например.
КД>Системные, это те которые пишут код там, где и механизма исключений как такового нет ?
Глупо считать, что системное ПО — это только то, что в режиме ядра.
В данном случае, системные — это те, которые, например, компиляторы пишут.
А про исключения почитайте того же Christophe de Dinechin (worked on exception handling and the C++ ABI for HP's C++ compiler, on a real-time test system for automotive electronics)
Некоторые его статьи есть в открытом доступе, например, "C++ Exception Handling for IA-64". http://grenouille-bouillie.blogspot.com/
Есть и более общая "C++ Exception Handling", только в платном доступе.
M>Как и ожидалось, вы просто не умеете пользоваться ексепшенами и RAII
Технологии нужны для того, чтобы _упрощать_ код, а не для того, чтобы его усложнять, затруднять достижение цели, а потом тащится "ах какой я умный".
Если эксепшны упрощают код — то я ими пользоваться буду. Там, где упрощают.
Если какое-то навороченное использование эксепшнов _не_ упрощает код, а его усложняет (вот тут пример привели с exception filters, которые есть более сложный код, чем проверка возвратов) — до свиданья, проверить коды возвратов мне удобнее.
Понимаете, тул для задачи, а не задача для тула. Если использование тула привносит заметный tool overhead — то я сделаю по старинке, будет и быстрее, и более maintainable в будущем.
Exceptions не повышают надежность. Ядро Линукса почти не валится. А там их нет.
Ядро виндов тоже почти не валится, а там они только в файловых системах, и то не все на них сделано.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Фишка в том, что в блоке catch() неизвестно, из какого из двух внутренних вызовов вылетел exception, и потому неизвестно, сколько откатывать. Единственный выход — обернуть каждый вызов в try/catch и _по-старому обрабатывать возврат кода ошибки_. MSS>Это очень большая проблема frame-based exceptions — в обработчике неизвестен точный момент их возникновения, а значит — точное состояние системы на момент возникновения, что создает сложности с откатом. Именно на это обращал внимание Остерман.
Кхм. Если вы РУКАМИ откатываете изменения в catch() — то вам уже ничего не поможет. С exception'ами нужно использовать RAII и автоматические обертки — тогда можно не думать о состоянии программы на момент возникновения исключения.
Конечно, в некоторых случаях это не очень удобно — в ядерном программировании, например. Но это уже частные случаи.
Здравствуйте, Maxim S. Shatskih, Вы писали:
M>>Как и ожидалось, вы просто не умеете пользоваться ексепшенами и RAII
MSS>Технологии нужны для того, чтобы _упрощать_ код, а не для того, чтобы его усложнять, затруднять достижение цели, а потом тащится "ах какой я умный".
MSS>Если эксепшны упрощают код — то я ими пользоваться буду. Там, где упрощают.
MSS>Если какое-то навороченное использование эксепшнов _не_ упрощает код, а его усложняет (вот тут пример привели с exception filters, которые есть более сложный код, чем проверка возвратов) — до свиданья, проверить коды возвратов мне удобнее.
MSS>Понимаете, тул для задачи, а не задача для тула. Если использование тула привносит заметный tool overhead — то я сделаю по старинке, будет и быстрее, и более maintainable в будущем.
Помоему ничто не портит код как разнообразие используемых в нем средств решения одной проблемы, в данном случае обработки ошибок.
MSS>Exceptions не повышают надежность. Ядро Линукса почти не валится. А там их нет.
MSS>Ядро виндов тоже почти не валится, а там они только в файловых системах, и то не все на них сделано.
Я видел много программ которые не валятся, как с исключениями так и с кодами возвратов. Тут все зависит от....
И второй вопрос. Что вы будите делать без обработки исключений когда у вас возникает ошибка во время конструирования объекта? Как решается эта проблема с механизмом исключений понятно. Например в моем коде вероятность ошибки во время конструирования вполне реальна, и я это без проблем решаю при помощи исключений. Других внятных способов пока не нашел.
Здравствуйте, Maxim S. Shatskih, Вы писали:
C>>Конечно, в некоторых случаях это не очень удобно — в ядерном программировании, например. MSS>Да и в любом системном, когда не ляпаешь из стандартных кубиков, а делаешь реально свой кубик.
Странно, у меня вот получается без всяких проблем.
MSS>В ядрах же другие проблемы, там, например, нет рантайма поддержки Си++ эксепшнов — только Си/Win32, которые __try/__except(EXCEPTION_EXECUTE_HANDLER).
Это понятно — просто технические ограничения. В Линуксе точно так же — в ядре вообще без извращений только на чистом С можно писать.
Я видел людей которые начинали пользоваться ексепшенами и RIIA и прониклись. Ни разу не встречал чтобы ктото из них хотел вести оьрабьотку ошибок через возвращаемые значения. Да и флеймить об этом в 2007 году даже не с руки.
Здравствуйте, Cyberax, Вы писали:
MSS>>В ядрах же другие проблемы, там, например, нет рантайма поддержки Си++ эксепшнов — только Си/Win32, которые __try/__except(EXCEPTION_EXECUTE_HANDLER). C>Это понятно — просто технические ограничения. В Линуксе точно так же — в ядре вообще без извращений только на чистом С можно писать.
Так исключения тут причем ? это другой язык , тут все в ручную by design.
Так бывает только в простейшем случае. В реале же, если обломилась Osilit1, то обработчик облома один, а если Osilit2 — то уже другой.
X>И второй вопрос. Что вы будите делать без обработки исключений когда у вас возникает ошибка во время конструирования объекта?
Это отвратительный ляпсус в Си++. Автор книг про COM Крайг Брокшмидт вообще советовать _не класть в конструктор ничего, что может обломиться_, а сделать еще метод Init.
И он прав.
X>Как решается эта проблема с механизмом исключений понятно. Например в моем коде вероятность ошибки во время конструирования вполне реальна
Я бы переписал код (если это Си++) так, как предлагает Брокшмидт.
Здравствуйте, Maxim S. Shatskih, Вы писали:
M>>Да и флеймить об этом в 2007 году даже не с руки. MSS>Почему? огромное количество кода написано вообще на Си или на Си++ без использования throw. MSS>Например, значительная часть серьезного опен-сорса.
Например, в ядре Линукса используется "эмуляция" исключений в виде "goto out/goto error_exit". Как раз чтобы убрать горы макаронного кода проверок.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Ну в реале-то оно не так. В реале, если обломилась Osilit2, то надо сделать undo Osilit1, и обработчики облома у всех разные.
Пожалуйста:
MSS>Это отвратительный ляпсус в Си++. Автор книг про COM Крайг Брокшмидт вообще советовать _не класть в конструктор ничего, что может обломиться_, а сделать еще метод Init.
Ага. Анекдот из шести слов: "C++ best practice from COM creator".
C>>Какие проблемы? MSS>Код для undo где писать?
В Osilit1. Реально обычно нужно вызывать cleanup-функции. В редких случаях можно написать локальный класс для какого-то уж слишком спецефического действия.
Если нужно для cleanup-функции добавить параметры — используем boost::bind. Тем более, что после SmallBufferOptimization связка boost::bind+boost::function работает всего где-то в 2 раза медленнее, чем простой вызов функции.
C>>Ага. Анекдот из шести слов: "C++ best practice from COM creator". MSS>Почему анекдот? очень здравые у него там идеи. Пользуешься, все работает, проблем в реальных проектах не возникает.
Ага, конечно...
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Оно и в виндах так используется. А еще в виндах используется нечто вроде: MSS>try MSS>{ MSS> ... MSS>} MSS>finally MSS>{ MSS> if( Object1Initialized ) MSS> DestroyObject1(); MSS> if( Object2Initialized ) MSS> DestroyObject2(); MSS>} MSS>Решительно не понимаю, чем этот ужас лучше, чем проверка и undo сразу (лексически) после проверки.
Меньше места занимает. Вот такой макаронный код:
char *str1=malloc(..);
if (doSomething(str1))
{
free(str1);
return -1;
}
char *str2=malloc(...);
if (doSomething2(str2))
{
free(str1);
free(str2);
return -1;
}
Превращается в намного более чистый и компактный:
int err=0;
char *str1=malloc(...);
if (err=doSomething(str1)) goto err_exit;
char *str2=malloc(...);
if (err=doSomething(str2)) goto err_exit;
return 0;
err_exit:
free(str1);
free(str2);
return err;
Здравствуйте, Maxim S. Shatskih, Вы писали:
C>>Например, в ядре Линукса используется "эмуляция" исключений в виде "goto out/goto error_exit". Как раз чтобы убрать горы макаронного кода проверок.
MSS>Оно и в виндах так используется. А еще в виндах используется нечто вроде:
MSS>try MSS>{ MSS> ... MSS>} MSS>finally MSS>{ MSS> if( Object1Initialized ) MSS> DestroyObject1(); MSS> if( Object2Initialized ) MSS> DestroyObject2(); MSS>}
MSS>Решительно не понимаю, чем этот ужас лучше, чем проверка и undo сразу (лексически) после проверки.
Бизнес логика приложения отделена от логики обработки исключительных ситуаций.
Здравствуйте, Maxim S. Shatskih, Вы писали:
M>>Так исключения тут причем ? это другой язык , тут все в ручную by design.
MSS>Превед
MSS>__try/__except(EXCEPTION_EXECUTE_HANDLER) будет работать и в Си++.
Повторюсь в раз 4-й , ексепшены в С++ by design расчитанны на использование RAII
То о чем вы пишете может использоваться только в качестве примеров из учебеиков. В грамотной программе обработчиков исключений можно посчитать по пальцам.
1. Исключение вызывается только в случае когда мы не можем продолжать выполнение логики работы или кода. Если мы можем чтолибо предпринять для продолжения работы или вернуть информацию на основании которой можно возобновить выполнение, исключения лучше не использовать(это уже дело вкуса и привычки).
2. Посколько на исключениях не завязанна логика то и делать в обработчиках, это сообщить комунмть о проблеме и решить что делать дальше.
3. Вся транзакционность , логика, управление ресурсами идет через RAII и ни в коем случае не через обработчик исключения(это грубое нарушение инкапсуляции и жесткое увеличение связанности).
Здравствуйте, minorlogic, Вы писали:
MSS>>Превед :)
MSS>>__try/__except(EXCEPTION_EXECUTE_HANDLER) будет работать и в Си++.
M>Повторюсь в раз 4-й , ексепшены в С++ by design расчитанны на использование RAII
M>http://en.wikipedia.org/wiki/RAII
Вот именно что "рассчитаны". Но этот расчёт базируется, по сути, на одном — на том, что разработчики считают, что если есть RAII, то ничего иного не должно уже быть, и делать try-finally в языке нет смысла.
Проблемой в этом подходе является то, что когда действие, которое надо откатить при выходе из функции, усложняется — вместо естественного подхода начинается искусственное выделение действий в RAII-класс. Из того, что мне реально приходилось строить — действие при входе в функцию и откат при выходе:
1. Замена значения внешней переменной.
2. Установка обработчика сигнала.
3. Сложные комбинации присваивания и вызова внешних функций (модификация части окружения).
4. Транзакционные операции с внешним хранилищем.
В результате — приходилось писать для таких вещей особый класс, и действие функции становилось менее понятным при чтении (как минимум приходилось ставить комментарий, что тут важная часть функциональности ушла во вспомогательный класс), вместо того, чтобы сделать
Вот потому мне и не нравится позиция разработчиков C++. Типичное "сегодня в колбасе потребности нет".
M>То о чем вы пишете может использоваться только в качестве примеров из учебеиков. В грамотной программе обработчиков исключений можно посчитать по пальцам.
Весьма странное утверждение (ещё одно?)
Может, в ряде задач так оно и будет. А вот в построении, например, сетевого взаимодействия со сложной логикой без достаточного количества обработчиков (значительно больше, чем на пальцах) не обойтись, потому что
1) Оно не имеет права вылетать только от того, что сокет закрыли с другой стороны (да, тут уже свойство библиотеки — она кидает исключение в таком случае).
2) внутренний событийный движок не должен дохнуть от того, что где-то в недрах одного обработчика произошло исключение.
3) само собой, очистные работы (удаление обработки запроса по закрытию соединения или присылке отказа от обработки) не должны прерываться ни в коем случае, кроме какой-то глобальной неустранимой проблемы вроде порчи динамической кучи), и их код состоит из сплошных try вокруг одного действия и catch с логгингом вокруг него.
Вот сейчас грепнул — 113 try'ев. После очистки от стилевых (защита от перезагрузки модулей) — 94. Это уже рабочий комплект.
Или 94 — это ещё "на пальцах"?
M>1. Исключение вызывается только в случае когда мы не можем продолжать выполнение логики работы или кода.
Да, не можем. Но не всей программы, а одного соединения. Остальное должно выживать.
Кстати, это совсем не сетевая специфика. Возьмём к примеру фотошоп. Должен ли он дохнуть целиком оттого, что один фильтр навернулся? Очевидно, нет. Мы можем разве что посоветовать юзеру "сохранись, выйди и перезапустись, программа уже в подозрительном состоянии". Но выбивать всю программу — ой нельзя.
M> Если мы можем чтолибо предпринять для продолжения работы или вернуть информацию на основании которой можно возобновить выполнение, исключения лучше не использовать(это уже дело вкуса и привычки).
В "мелком" случае это действительно стилевщина и вкусовщина:) Но не в большом комплексе.
M>2. Посколько на исключениях не завязанна логика то и делать в обработчиках, это сообщить комунмть о проблеме и решить что делать дальше.
Кому сообщать-то? Вот у меня демон должен жить как можно дольше и устойчивее, пока нет данных о нарушении базовой подложки (фактически, куча и несколько глобальных переменных). Да, исключения пишутся в лог и этот лог читается при подозрении на баг (скоро ещё сделаем автоотправку разработчикам). Выкидывать окошко о проблеме — кому? Дежурному системы мониторинга?
M>3. Вся транзакционность , логика, управление ресурсами идет через RAII и ни в коем случае не через обработчик исключения(это грубое нарушение инкапсуляции и жесткое увеличение связанности).
M>http://en.wikipedia.org/wiki/RAII
Скучная страничка. Там слишком узко понимают "потребление ресурсов". См. выше про finally.
Здравствуйте, minorlogic, Вы писали:
M>Прошу воспринимать мой пост как рекомендации . Best practices
1. Это невозможно воспринимать как "best practices", пока есть массовые случаи противоречия постулатам (типа "RAII правильно, всё остальное не нужно"). Если Ваш случай проще... что ж, могу просто позавидовать. Мне такая простота недоступна, и "колбаса" нужна.
2. По процедуре: Вы злоупотребляете, jIMHO, срезанием квотинга. Ни в почте, ни в моём показе (я воспринимаю только линейный показ, дерево в таких форумах для меня громоздко и неудобно) непонятно, к чему относятся замечания. Особенно предыдущее про "звучат заблуждениями".
Здравствуйте, netch80, Вы писали:
N>В результате — приходилось писать для таких вещей особый класс, и действие функции становилось менее понятным при чтении (как минимум приходилось ставить комментарий, что тут важная часть функциональности ушла во вспомогательный класс), вместо того, чтобы сделать
N>
N>что, по-моему, в разы более ясно для понимания.
А по моему это довольно архаичный стиль и уж точно хуже для понимания. Спорить по этому поводу я не готов и нет желания, останемся при своих. Для меня вполне узнаваемым будет код с объектами transaction (command ми т.п.).
M>>То о чем вы пишете может использоваться только в качестве примеров из учебеиков. В грамотной программе обработчиков исключений можно посчитать по пальцам.
N>Весьма странное утверждение (ещё одно?)
Это моя личная рекомендация.
N>Может, в ряде задач так оно и будет. А вот в построении, например, сетевого взаимодействия со сложной логикой без достаточного количества обработчиков (значительно больше, чем на пальцах) не обойтись, потому что
Не вижу причеин по которым сетевые взаимодействия могут иметь свою специфику в плане обработки исключений.
N>Вот сейчас грепнул — 113 try'ев. После очистки от стилевых (защита от перезагрузки модулей) — 94. Это уже рабочий комплект.
N>Или 94 — это ещё "на пальцах"?
Я сразу подозреваю пробелы в дизайне и логику приложения использующуюся в блоках try catch
M>>1. Исключение вызывается только в случае когда мы не можем продолжать выполнение логики работы или кода.
N>Да, не можем. Но не всей программы, а одного соединения. Остальное должно выживать. N>Кстати, это совсем не сетевая специфика. Возьмём к примеру фотошоп. Должен ли он дохнуть целиком оттого, что один фильтр навернулся? Очевидно, нет. Мы можем разве что посоветовать юзеру "сохранись, выйди и перезапустись, программа уже в подозрительном состоянии". Но выбивать всю программу — ой нельзя.
С этим странно спорить и комментировать, не знаю с чего вы решили что я утверждал обратное.
M>>2. Посколько на исключениях не завязанна логика то и делать в обработчиках, это сообщить комунмть о проблеме и решить что делать дальше.
N>Кому сообщать-то? Вот у меня демон должен жить как можно дольше и устойчивее, пока нет данных о нарушении базовой подложки (фактически, куча и несколько глобальных переменных). Да, исключения пишутся в лог и этот лог читается при подозрении на баг (скоро ещё сделаем автоотправку разработчикам). Выкидывать окошко о проблеме — кому? Дежурному системы мониторинга?
"сообщить комунмть" это не значит выкинуть окошко. Это означает проинформировать вызывающую сторону о невозможности выполнить действие.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, minorlogic, Вы писали:
M>>Прошу воспринимать мой пост как рекомендации . Best practices
N>1. Это невозможно воспринимать как "best practices", пока есть массовые случаи противоречия постулатам (типа "RAII правильно, всё остальное не нужно"). Если Ваш случай проще... что ж, могу просто позавидовать. Мне такая простота недоступна, и "колбаса" нужна.
Я не навязываю, даже внутри нашей команды я бы не стал навязывать свое мнение своим коллегам.
N>2. По процедуре: Вы злоупотребляете, jIMHO, срезанием квотинга. Ни в почте, ни в моём показе (я воспринимаю только линейный показ, дерево в таких форумах для меня громоздко и неудобно) непонятно, к чему относятся замечания. Особенно предыдущее про "звучат заблуждениями".
Я предполагаю что ветка читается последовательно и всегда можно вернуться на ступеньку. Спасибо , попробую исправиться.
Здравствуйте, minorlogic, Вы писали:
N>>} finally { N>>что, по-моему, в разы более ясно для понимания. M>А по моему это довольно архаичный стиль и уж точно хуже для понимания. Спорить по этому поводу я не готов и нет желания, останемся при своих. Для меня вполне узнаваемым будет код с объектами transaction (command ми т.п.).
Архаичным он наверняка не может быть, за отсутствием finally до языков с обработкой исключений, и в C++ вообще:) А спорить — а что тут спорить, если сам Страуструп сказал "никаких сусликов"? Несмотря на то, что большинство других допускают finally если даже есть немедленная деструкция (как в питоне через счётчик и __del__).
N>>Может, в ряде задач так оно и будет. А вот в построении, например, сетевого взаимодействия со сложной логикой без достаточного количества обработчиков (значительно больше, чем на пальцах) не обойтись, потому что M>Не вижу причеин по которым сетевые взаимодействия могут иметь свою специфику в плане обработки исключений.
Попросите у ближайшего эрланговца эпохальный диссер Армстронга про устойчивость сетевых приложений в телекоммуникационной сфере:))) Специфика есть, и она именно в том, что даже если какой-то один модуль глюкает и отработка звонка (соединения, etc.) обломалась — остальное должно работать и с минимальной завязкой на проблемы того уровня. В случае такой защиты и подложки с собственным управлением памятью (i.e. c GC) я это имею (даже на Питоне, не говоря уж про Erlang). Так что — причины есть.
netch80 wrote: > try { > подготовка обстановки; > работа; > } finally { > восстановление обстановки; > }
Проблема тут в том, что можно забыть добавить нужное
cleanup-действие в "восстановление обстановки". А учитывая, что
exception conditions часто не тестируются и проблемы от утекающих
ресурсов могут быть заметны не сразу — баг может жить очень долго.
В этом отношении RAII намного лучше — мы уже не можем забыть освободить
ресурс (ну если _очень_ не захочем).
Количество необходимых служебных классов, на практике, у меня получается
очень небольшим. ON_BLOCK_EXIT + boost::bind справляются с 90% случаев.
Здравствуйте, minorlogic, Вы писали:
M>Больше похоже что обычные рабочие ситуации которых из которых и состоит работа вы проецируете на каеи то свои мании. Это естествено что кто то чего то не знает, а другой знает.
Согласен. Совершенно жизненные ситуации. Люди привыкли, а свежим глазом оно как-то вдруг увиделось
>> try { >> подготовка обстановки; >> работа; >> } finally { >> восстановление обстановки; >> } C>Проблема тут в том, что можно забыть добавить нужное C>cleanup-действие в "восстановление обстановки". C>В этом отношении RAII намного лучше — мы уже не можем забыть освободить C>ресурс (ну если _очень_ не захочем).
это как раз ещё один случай, где очень удобны лямбды. вот как это выглядит в хаскеле:
bracket (openFile filename) closeFile \$ handle -> do
x <- readLn handle
...
действие closeFile синтаксически описывается рядом с openFile и будет выполнено над возвращённым хендлом в обоих случаях. более того, это легко выделить в отлельную функцию — это будет аналог вашего служебного класса:
withFile filename = bracket (openFile filename) closeFile
withFile "autoexec.bat" \$ handle -> do
x <- readLn handle
...
плюс к этому, логика try/finally жёстко задана в компиляторе, а при использовании функций/классов в них легкко можно добавить свои погремушки. я например недавно таким образом добавил обработку ^Breal
C>Количество необходимых служебных классов, на практике, у меня получается C>очень небольшим. ON_BLOCK_EXIT + boost::bind справляются с 90% случаев.
а как выглядит этот код? как я понимаю, те же лямбды, только сахар не такой сладкий?
Здравствуйте, Cyberax, Вы писали:
C>netch80 wrote: >> try { >> подготовка обстановки; >> работа; >> } finally { >> восстановление обстановки; >> } C>Проблема тут в том, что можно забыть добавить нужное C>cleanup-действие в "восстановление обстановки". А учитывая, что C>exception conditions часто не тестируются и проблемы от утекающих C>ресурсов могут быть заметны не сразу — баг может жить очень долго.
Неправда. Если место очистки только одно — записать в finally нужное восстановление не сложнее, чем в сделанном для этого классе (тут безо всяких IMHO), а как по мне — даже значительно проще (вот тут уже IMHO), потому что логика записана явно и линейно, а не через какие-то находящиеся за несколько экранов деструкторы.
Вот если бы было много мест выхода — да, там элементарно забыть нужное восстановление (и это очень распространённая ошибка). Но здесь явно один finally, а не много.
C>В этом отношении RAII намного лучше — мы уже не можем забыть освободить C>ресурс (ну если _очень_ не захочем).
Мы можем его не записать в классе, сконструированном специально для данной частной обработки, и (повторюсь) это сделать легче и контролировать сложнее, чем в случае кода, находящегося в той же функции.
C>Количество необходимых служебных классов, на практике, у меня получается C>очень небольшим. ON_BLOCK_EXIT + boost::bind справляются с 90% случаев.
Кто такой ON_BLOCK_EXIT? И всё равно это означает код, угнанный куда-то далеко за пределы непосредственной видимости.
N>Неправда. Если место очистки только одно — записать в finally нужное восстановление не сложнее, чем в сделанном для этого классе (тут безо всяких IMHO),
фишка в том, что в try/finally получение и освобождение ресурса синтаксически разделены кодом его обработки, поэтому отсутствующее в finally его совобождение не бросается в глаза (надеюсь не надо лишний раз говорить, что его можно забыть вставить, отвлёкшись на решение других задач, можно удалить на время и забыть восстановить, можно неаккуратно прорефакторить и т.д.)
когда у тебя класс, который занят только следжкой за этим ресурсом — там пропуск освобождения сразу бросается в глаза. в моём примере на хаскеле ещё хуже — это просто не пропустит система типов
Здравствуйте, BulatZiganshin, Вы писали:
N>>Неправда. Если место очистки только одно — записать в finally нужное восстановление не сложнее, чем в сделанном для этого классе (тут безо всяких IMHO),
BZ>фишка в том, что в try/finally получение и освобождение ресурса синтаксически разделены кодом его обработки, поэтому отсутствующее в finally его совобождение не бросается в глаза (надеюсь не надо лишний раз говорить, что его можно забыть вставить, отвлёкшись на решение других задач, можно удалить на время и забыть восстановить, можно неаккуратно прорефакторить и т.д.)
Ну вот потому я и ограничил эту часть мнения явной меткой "IMHO". Вам удобнее видеть эти действия в классе рядом — не вопрос. Но мне сама вынесенность класса из основного кода мешает. А разделение кодом обработки... если функция сделана по рекомендациям лучших собаководов (не более полутора экранов, или даже не более 25 строк) — оно и незаметно.
BZ>>а как выглядит этот код? как я понимаю, те же лямбды, только сахар не такой сладкий?
FR>Со сладким сахаром есть в D Programming Language смотри scope exit тут http://www.digitalmars.com/d/exception-safe.html
ну вот собственно он и говорит ровно о том же:
Both solutions work, but both have drawbacks. The RAII solution often requires the creation of an extra dummy class, which is both a lot of lines of code to write and a lot of clutter obscuring the control flow logic. This is worthwhile to manage resources that must be cleaned up and that appear more than once in a program, but it is clutter when it only needs to be done once. The try-finally solution separates the unwinding code from the setup, and it can often be a visually large separation. Closely related code should be grouped together.
хотя думаю, что слаще было бы это сделать на клозурах. в руби, например, такое возможно
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>хотя думаю, что слаще было бы это сделать на клозурах. в руби, например, такое возможно
FR>А зачем там замыкания, scope exit по сути специализированный блок кода (на руби же через них и будет).
разница исключительно в том, что для решения 10 разных порблем лучше ввести в язык один универсальный механизм, чем 10 специфичных
Здравствуйте, BulatZiganshin, Вы писали:
BZ>разница исключительно в том, что для решения 10 разных порблем лучше ввести в язык один универсальный механизм, чем 10 специфичных
Главное чтоб он был удобным, иначе пользоваться не будут, или все равно разобьют на 10 специфичных.
ЗЫ Хотя, больше к словам придирка .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
BZ>>разница исключительно в том, что для решения 10 разных порблем лучше ввести в язык один универсальный механизм, чем 10 специфичных
DC>Главное чтоб он был удобным, иначе пользоваться не будут, или все равно разобьют на 10 специфичных.
ортогональность сама по себе — очень важна для языка. просто представь себе описание языка скажем на 100 и 1000 страниц. или 1000 и 10000
Здравствуйте, BulatZiganshin, Вы писали:
BZ>>>разница исключительно в том, что для решения 10 разных порблем лучше ввести в язык один универсальный механизм, чем 10 специфичных
DC>>Главное чтоб он был удобным, иначе пользоваться не будут, или все равно разобьют на 10 специфичных.
BZ>ортогональность сама по себе — очень важна для языка. просто представь себе описание языка скажем на 100 и 1000 страниц. или 1000 и 10000
Да чего там. Стандарты С++ и Haskell сравнить хотя бы.
ЗЫ Тема уже переросла в "Казалось бы, причем здесь Хаскел?" .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, BulatZiganshin, Вы писали:
DC>>ЗЫ Тема уже переросла в "Казалось бы, причем здесь Хаскел?" .
BZ>как и любая другая с моим участием. не дай бог, придёт Влад
Та да, конструктив пропадет, зато истину иска будем .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, netch80, Вы писали:
C>>Проблема тут в том, что можно забыть добавить нужное C>>cleanup-действие в "восстановление обстановки". А учитывая, что C>>exception conditions часто не тестируются и проблемы от утекающих C>>ресурсов могут быть заметны не сразу — баг может жить очень долго. N>Неправда. Если место очистки только одно — записать в finally нужное восстановление не сложнее, чем в сделанном для этого классе (тут безо всяких IMHO), а как по мне — даже значительно проще (вот тут уже IMHO), потому что логика записана явно и линейно, а не через какие-то находящиеся за несколько экранов деструкторы.
Правда — тебе надо вернуться вниз и дописать код в finally. Это элементарно можно забыть (видел не раз). Деструкторы вообще пофиг где находятся — нам их видеть не обязательно.
C>>В этом отношении RAII намного лучше — мы уже не можем забыть освободить C>>ресурс (ну если _очень_ не захочем). N>Мы можем его не записать в классе, сконструированном специально для данной частной обработки, и (повторюсь) это сделать легче и контролировать сложнее, чем в случае кода, находящегося в той же функции.
Ничуть не сложнее. Запрещаете явные вызовы close/destroy/free — и все магически поправляется очень быстро. Лично пробовал на своей команде.
C>>Количество необходимых служебных классов, на практике, у меня получается C>>очень небольшим. ON_BLOCK_EXIT + boost::bind справляются с 90% случаев. N>Кто такой ON_BLOCK_EXIT? И всё равно это означает код, угнанный куда-то далеко за пределы непосредственной видимости.
Мда. http://www.ddj.com/dept/cpp/184403758
Здравствуйте, BulatZiganshin, Вы писали:
C>>Количество необходимых служебных классов, на практике, у меня получается C>>очень небольшим. ON_BLOCK_EXIT + boost::bind справляются с 90% случаев. BZ>а как выглядит этот код? как я понимаю, те же лямбды, только сахар не такой сладкий?
Смотри остальные сообщения. Да, bind — это простейший случай лямбд.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, netch80, Вы писали:
C>>>Проблема тут в том, что можно забыть добавить нужное C>>>cleanup-действие в "восстановление обстановки". А учитывая, что C>>>exception conditions часто не тестируются и проблемы от утекающих C>>>ресурсов могут быть заметны не сразу — баг может жить очень долго. N>>Неправда. Если место очистки только одно — записать в finally нужное восстановление не сложнее, чем в сделанном для этого классе (тут безо всяких IMHO), а как по мне — даже значительно проще (вот тут уже IMHO), потому что логика записана явно и линейно, а не через какие-то находящиеся за несколько экранов деструкторы. C>Правда — тебе надо вернуться вниз и дописать код в finally. Это элементарно можно забыть (видел не раз).
Забыть, что данные действия надо вернуть назад, ещё проще — тогда не надо создавать никаких обёрточных классов.:))
C> Деструкторы вообще пофиг где находятся — нам их видеть не обязательно.
Что, в другом файле, чем конструктор? Вот за это точно канделябром.
N>>Кто такой ON_BLOCK_EXIT? И всё равно это означает код, угнанный куда-то далеко за пределы непосредственной видимости. C>Мда. http://www.ddj.com/dept/cpp/184403758
Здравствуйте, netch80, Вы писали:
C>>Правда — тебе надо вернуться вниз и дописать код в finally. Это элементарно можно забыть (видел не раз). N>Забыть, что данные действия надо вернуть назад, ещё проще — тогда не надо создавать никаких обёрточных классов.
Понимаешь, я при написании кода и соблюдении простейших правил вообще в принципе не могу забыть освободить ресурсы. Ну разве что если не постараюсь и не сделаю циклические ссылки где-нибудь, но это уже ошибка логики.
C>> Деструкторы вообще пофиг где находятся — нам их видеть не обязательно. N>Что, в другом файле, чем конструктор? Вот за это точно канделябром.
Я имею в виду про деструкторы ресурсов. Мне абсолютно пофиг при использовании boost::scoped_lock иди file_handle_t в каком файле оно определено. Главное, что мне гарантировано их освобождение.
N>>>Кто такой ON_BLOCK_EXIT? И всё равно это означает код, угнанный куда-то далеко за пределы непосредственной видимости. C>>Мда. http://www.ddj.com/dept/cpp/184403758 N>Ага, ну если такой изврат, то ещё как-то терпимо.
Изврат — это писать в стиле С
Здравствуйте, netch80, Вы писали:
N>Попросите у ближайшего эрланговца эпохальный диссер Армстронга про устойчивость сетевых приложений в телекоммуникационной сфере Специфика есть, и она именно в том, что даже если какой-то один модуль глюкает и отработка звонка (соединения, etc.) обломалась — остальное должно работать и с минимальной завязкой на проблемы того уровня. В случае такой защиты и подложки с собственным управлением памятью (i.e. c GC) я это имею (даже на Питоне, не говоря уж про Erlang). Так что — причины есть.
Погоди, но в Эрланге это все отдельными процессами сделано. Т.е. процесс умер, сделали заново и работаем. Дык кто тебе в плюсах мешает запустить код который отвечает за коммуникацию в отдельный процесс? Вот и получим надежность на уровне Эрланга.
Только это несколько не в сторону исключений камень, т.к. очень трудно в рамках испорченного контекста выполнения произвести нормальное восстановление, по одной простой причине — может быть испорчен хип или стек или какая-нибудь глобальная переменная и выяснить это практически нереально.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, dr.Chaos, Вы писали:
DC>Здравствуйте, netch80, Вы писали:
N>>Попросите у ближайшего эрланговца эпохальный диссер Армстронга про устойчивость сетевых приложений в телекоммуникационной сфере:))) Специфика есть, и она именно в том, что даже если какой-то один модуль глюкает и отработка звонка (соединения, etc.) обломалась — остальное должно работать и с минимальной завязкой на проблемы того уровня. В случае такой защиты и подложки с собственным управлением памятью (i.e. c GC) я это имею (даже на Питоне, не говоря уж про Erlang). Так что — причины есть.
DC>Погоди, но в Эрланге это все отдельными процессами сделано. Т.е. процесс умер, сделали заново и работаем. Дык кто тебе в плюсах мешает запустить код который отвечает за коммуникацию в отдельный процесс? Вот и получим надежность на уровне Эрланга.
Мешает то, что если это настоящие системные процессы, то подход крайне дорог и слабо масштабируем (то что в Erlang зовётся "процессами" это отнюдь не системные сущности), а если что-то внутри среды управления — то управление памятью со стороны программиста, а не исполняющей среды (как в C, C++ и так далее) — убьёт надёжность за счёт memory leaks, если не чего-то похуже. И синхронизация на общих объектах невозможна (не смог освободить мьютекс => опаньки).
DC>Только это несколько не в сторону исключений камень, т.к. очень трудно в рамках испорченного контекста выполнения произвести нормальное восстановление, по одной простой причине — может быть испорчен хип или стек или какая-нибудь глобальная переменная и выяснить это практически нереально.
Вот именно. Erlang берёт здесь тем, что на уровне среды исполнения отграничивает эти "процессы". Это тоже не всегда работает (например, при взаимодействии с железом), но в большинстве случаев — да. Система другого рода, но с GC и исключениями, даёт некоторое приближение к такой надёжности (не идеальное, но меня устраивает). Но если мне, как давешний оппонент, чуть ли не запрещают перехватывать исключения — я ничего не получаю.
N>Вот именно. Erlang берёт здесь тем, что на уровне среды исполнения отграничивает эти "процессы". Это тоже не всегда работает (например, при взаимодействии с железом), но в большинстве случаев — да. Система другого рода, но с GC и исключениями, даёт некоторое приближение к такой надёжности (не идеальное, но меня устраивает). Но если мне, как давешний оппонент, чуть ли не запрещают перехватывать исключения — я ничего не получаю.
разница имхо в том, что эрланговская порграмма в приницпе не может изгадить память. в эрланге просто нет указателей сужу по своему опыту работы с haskell'ом — за 3 года только однажды я что-то непотребное сотоворил. соответственно крах эпланговой нити не означает, что она изгадит общее пространство памяти, разделяемое с другими нитями — это чисто алгоритмический крах из-за того, что алгоритм не предусматривает обработку какой-либо ситуации
в С++ это конечно тоже будет работать, и от алгоритмических недоделок защитит. проблема в том, что в C++ есть ошибки и другого рода — когда похабится память. и для того, чтобы защититься от них, надо или использовать исключительно высокоуровневый подход к программированию (никакой ссылочной арифметики) ии вообще другой язык
N>Мешает то, что если это настоящие системные процессы, то подход крайне дорог и слабо масштабируем (то что в Erlang зовётся "процессами" это отнюдь не системные сущности), а если что-то внутри среды управления — то управление памятью со стороны программиста, а не исполняющей среды (как в C, C++ и так далее) — убьёт надёжность за счёт memory leaks, если не чего-то похуже. И синхронизация на общих объектах невозможна (не смог освободить мьютекс => опаньки).
Что касается настоящи мьютексов, то
If a thread terminates without releasing its ownership of a mutex object, the mutex object is considered to be abandoned. A waiting thread can acquire ownership of an abandoned mutex object, but the wait function's return value indicates that the mutex object is abandoned.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
X>>1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?
MSS>Вы точно уверены, что хотите на ходу посреди проекта менять сорс-контрол?
Конечно, это задача не самого высокого приоритета, но я тем не менее выделил бы пару человеко-дней чтобы этим заняться. Поскольку если в проекте ещё планируется несколько человеко-месяцев, то эти затраты окупятся со 100% вероятностью. Переход на SVN с различных VCS довольно хорошо обкатан, есть куча руководств и рекомендаций в инете. Всего, конечно, не предусмотришь — но не так страшен чёрт.
MSS>Не в сорс-контроле дело тут, а в руках и мозгах. Можно и на VSS работать на порядок качественнее, чем обсуждаемая команда. А можно и на TFS запутаться.
Аргумент из разряда "нафиг C, если есть мозги то можно и на asm-е писАть". Мастера узнают по инструментам. SVN реально более прогрессивный инструмент, который по фичерам и удобству кроет VSS как бык овцу. Для небольших или уже законченых (в стадии поддержки) проектов я готов смириться с отсталым VCS. Проект в стадии активной разработки — должет лежать в нормальной современной VCS (читай — SVN ) — потому что удобство + фичеры (даже если они поначалу кажутся копеешными и не такими уж нужными) — в итоге дадут значительную экономию времени (читай — денег ).
MSS>Мдаа... расскажите нам (аудитории форума), в чем смысл версио-мании и гонки за последними версиями, особенно в условиях, когда речь о большом объеме старого кода.
Конечно, гнаться за последними версиями — это не зло, поскольку обрекаешь себя на хождение по неразведанным граблям. Но и плестись в хвосте тоже нет смысла — в конце концов такие вещи как runtime checks или дебажные версии STL могут помочь найти довольно трудноуловимые в других условиях баги. К тому же опять же — опыт показывает что не так уж сложен переход с 6-ки на 2003(2005)-ю студию.
MSS>На 5 человек?
5 >= 2. Да, на 5 человек — уже оправдано. Это ещё для одного можно было бы подумать.
MSS>Вот это — дело. Тут скорее вопрос — "почему вообще терпите такого слабого девелопера".
Не, тут вопрос скорее административный всё же. Девелопер может быть и хорошим, просто не привык работать в команде или нет культуры работы с VCS.
MSS>На моей бывшей работе codestyle вырабатывали 4 лида целый рабочий день минимум (или два, не помню уж), и консенсусу — кроме совсем основополагающих вещей — не пришли.
Ага. Не пришли. Я сам в таком шабаше учавствовал пару раз. Но плохой codestyle — хуже полного его отсутствия. Ну, кроме клинических случаев, конечно
L>Конечно, гнаться за последними версиями — это не зло, поскольку обрекаешь себя на хождение по неразведанным граблям. Но и плестись в хвосте тоже нет смысла — в конце концов такие вещи как runtime checks или дебажные версии STL могут помочь найти довольно трудноуловимые в других условиях баги. К тому же опять же — опыт показывает что не так уж сложен переход с 6-ки на 2003(2005)-ю студию.
Пардон, вместо "гнаться за последними версиями — это не зло" следует читать "гнаться за последними версиями — это зло". Обязуюсь впредь подобных описок не допускать .
Так и хочется сказать фразой из "IT Crowd": "Common, are you from past?"
Не обижайся ( ), но рекламирование стиля написания С++-программ с неиспользованием RAII — это что-то из прошлого века. Да, если ты привык так писать то возможно лично тебе так удобнее. Но если ты ходишь на руках быстрее чем большинство народа бегает ногами — это не значит что всем правильнее будет ходить на руках.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, netch80, Вы писали:
N>>Мешает то, что если это настоящие системные процессы, то подход крайне дорог и слабо масштабируем (то что в Erlang зовётся "процессами" это отнюдь не системные сущности), а если что-то внутри среды управления — то управление памятью со стороны программиста, а не исполняющей среды (как в C, C++ и так далее) — убьёт надёжность за счёт memory leaks, если не чего-то похуже. И синхронизация на общих объектах невозможна (не смог освободить мьютекс => опаньки).
КД>Что касается настоящи мьютексов, то
КД>
КД>If a thread terminates without releasing its ownership of a mutex object, the mutex object is considered to be abandoned. A waiting thread can acquire ownership of an abandoned mutex object, but the wait function's return value indicates that the mutex object is abandoned.
Во-первых, Вы бы приводили источник цитаты, а то гуглить когда кто-то просто не сказал где — немного обидно.
Во-вторых, это (нашёл уж, цитата из MSDN) про виндовые мьютексы. А зачем _мне_ рассказ про винду? Для меня актуальны pthreads, или в крайнем случае SysV IPC.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, dr.Chaos, Вы писали:
DC>>Здравствуйте, netch80, Вы писали:
N>>>Попросите у ближайшего эрланговца эпохальный диссер Армстронга про устойчивость сетевых приложений в телекоммуникационной сфере Специфика есть, и она именно в том, что даже если какой-то один модуль глюкает и отработка звонка (соединения, etc.) обломалась — остальное должно работать и с минимальной завязкой на проблемы того уровня. В случае такой защиты и подложки с собственным управлением памятью (i.e. c GC) я это имею (даже на Питоне, не говоря уж про Erlang). Так что — причины есть.
DC>>Погоди, но в Эрланге это все отдельными процессами сделано. Т.е. процесс умер, сделали заново и работаем. Дык кто тебе в плюсах мешает запустить код который отвечает за коммуникацию в отдельный процесс? Вот и получим надежность на уровне Эрланга.
N>Мешает то, что если это настоящие системные процессы, то подход крайне дорог и слабо масштабируем (то что в Erlang зовётся "процессами" это отнюдь не системные сущности), а если что-то внутри среды управления — то управление памятью со стороны программиста, а не исполняющей среды (как в C, C++ и так далее) — убьёт надёжность за счёт memory leaks, если не чего-то похуже. И синхронизация на общих объектах невозможна (не смог освободить мьютекс => опаньки).
Погоди тебе шашечки или ехать? Вот такой С++ инструмент, придется все самому делать. Если не хочется бери более развитый инструмент.
DC>>Только это несколько не в сторону исключений камень, т.к. очень трудно в рамках испорченного контекста выполнения произвести нормальное восстановление, по одной простой причине — может быть испорчен хип или стек или какая-нибудь глобальная переменная и выяснить это практически нереально.
N>Вот именно. Erlang берёт здесь тем, что на уровне среды исполнения отграничивает эти "процессы". Это тоже не всегда работает (например, при взаимодействии с железом), но в большинстве случаев — да. Система другого рода, но с GC и исключениями, даёт некоторое приближение к такой надёжности (не идеальное, но меня устраивает). Но если мне, как давешний оппонент, чуть ли не запрещают перехватывать исключения — я ничего не получаю.
Ну на С++ если все в RAII заворачивать и lock-free пользовать, STM всякий, т.е. более продвинутыми возможностями, тоже можно много добиться, просто там граблей больше.
Просто тут человек говорил про то, что очень трудно восстановиться после исключения. Собственно в Эрланг дается на это простой ответ, упал и пофиг, новый запустим, т.е. происходит восстановление работоспособности, а не восстановление контекста после исключения. В С++ тоже можно такой подход применять, только многое руками делать придеться.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, netch80, Вы писали:
КД>>Что касается настоящи мьютексов, то
N>Во-первых, Вы бы приводили источник цитаты, а то гуглить когда кто-то просто не сказал где — немного обидно. N>Во-вторых, это (нашёл уж, цитата из MSDN) про виндовые мьютексы.
Звиняйте
N>А зачем _мне_ рассказ про винду? Для меня актуальны pthreads, или в крайнем случае SysV IPC.
Настоящем программисту ... не помеха
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Я может туплю, но по-моему без исключений откаты организовать еще сложнее. Я конечно ядра OC не писал, но хорошо помню упрощение в реализации отказоустойчивого кода, когда перешел на использование исключения.
), но рекламирование стиля написания С++-программ с неиспользованием RAII — это что-то из прошлого века. Да, если ты привык так писать то возможно лично тебе так удобнее. Но если ты ходишь на руках быстрее чем большинство народа бегает ногами — это не значит что всем правильнее будет ходить на руках.
