Здравствуйте, 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... Что ставить надо? Откуда слить?

Я поставил DokuWiki + Apache + PHP. Это простенькая вики, которая даже базу не использует, все хранится в текстовых файлах.
http://www.splitbrain.org/projects/dokuwiki

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

X>>2. Почему мы еще не перешли на Visual Studio 2005 а все еще юзаем 6.0???

AZ>Потому, что если VC 6.0 прекрасно справляется с поставленной задачей, то нет причин переходить на VS2005.

Есть, есть

И отговорки типа "нафиг не надо", это всего лишь способ самоуспокоения

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


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-а преодолеваются с помощью вот этой

Автор: 0xDEADBEEF
Дата: 05.10.05

фичи. Я до сих пор в шоке, почему я сам до этого не допер

Есть еще что-то?

---

Вообще странно когда 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 — в обработчике неизвестен точный момент их возникновения, а значит — точное состояние системы на момент возникновения, что создает сложности с откатом. Именно на это обращал внимание Остерман.

Поддержка кода написанного с проверной кода возврата значительно сложнее в поддержке. На уровне ядра ОСи когда надо вернуть в исходное состояние процесс после эксепшена, гораздо проще его убить и запустить заново. Просто архитектура ОС у нас монолитная, а не миркоядерная.

Лично мне обертки — намного больший гимор, чем Win32.

M>А как эти сложности решаются без исключений ?

Lock(&lock);
код1 ... код1... код1...
Status = CallDown1();
if( !NT_SUCCESS(Status) )
{
undo кода1... undo кода1...
Unlock(&lock);
return Status;
}
код2... код2... код2...
Status = CallDown2();
if( !NT_SUCCESS(Status) )
{
undo кода2... undo кода2...
undo кода1.... undo кода1...
Unlock(&lock);
return Status;
}
Unlock(&lock);

При использовании SEH вам придется завернуть каждый CallDown в свой маленький SEH фрейм, и дальше сделать то же самое, что выше.

КД>Вообще странно когда MVP сетует на какие-то проблемы с исключениями.

Почему? в моих реальных задачах они мне не нужны просто

Здравствуйте, Коваленко Дмитрий, Вы писали:


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", только в платном доступе.

ggg>Глупо считать, что системное ПО — это только то, что в режиме ядра.
ggg>В данном случае, системные — это те, которые, например, компиляторы пишут.

Ага. SQL Server в общем тоже — если говорить о его разработчиках, а не о тех, кто его как платформу пользует.

Остерман (в прошлом автор SMB клиента) уже давно не в ядре.

Как и ожидалось, вы просто не умеете пользоваться ексепшенами и RAII

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>Ядро виндов тоже почти не валится, а там они только в файловых системах, и то не все на них сделано.

Я видел много программ которые не валятся, как с исключениями так и с кодами возвратов. Тут все зависит от....

Какой по вашему наиболее читабельный код?

void f()
{
  if(!SUCCESS(Osilit1()))
    NeOsilil();
  if(!SUCCESS(Osilit2()))
    NeOsilil();
  if(!SUCCESS(Osilit3()))
    NeOsilil();
  if(!SUCCESS(Osilit4()))
    NeOsilil();
  if(!SUCCESS(Osilit5()))
    NeOsilil();
}

Или

void f()
{
  try {
    Osilit1();
    Osilit2();
    Osilit3();
    Osilit4();
    Osilit5();
  catch(...)
  {
    NeOsilil();
  }
}

И второй вопрос. Что вы будите делать без обработки исключений когда у вас возникает ошибка во время конструирования объекта? Как решается эта проблема с механизмом исключений понятно. Например в моем коде вероятность ошибки во время конструирования вполне реальна, и я это без проблем решаю при помощи исключений. Других внятных способов пока не нашел.

C>Конечно, в некоторых случаях это не очень удобно — в ядерном программировании, например.

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

В ядрах же другие проблемы, там, например, нет рантайма поддержки Си++ эксепшнов — только Си/Win32, которые __try/__except(EXCEPTION_EXECUTE_HANDLER).