Исключения есть всегда, но в общей массе в этом плане все грустно. Близко познакомиться можно и за несколько месяцев вполне, я писал про, скажем так, экспертные знания в какой-либо области или технологии, так как именно такого рода знания могут выгодно выделять вас от остальных и как следствие повышать ваши шансы на успех, в плане поиска хорошего места работы с достойной оплатой вашего труда. Про собеседования в таких компаниях это вообще отдельный разговор. Хотят за копейки найти супер-гуру, причем что самое смешное, в большинстве случаев, такого уровня человек и не нужен в проекте, так как скорее всего заниматься придется намного более приземленными и банальными вещами, чем те, которыми вас пытают на собеседке. Ну как я уже написал, это отдельный разговор, который уже много раз обсуждался, в том числе и на том же rsdn. Вот еще вы правльно заметили про людей, «которые как бы уже от всего устали», этакий баласт-планктон, которые обычно сидят на поддерже какого-нибудь старого большого проекта, большую часть времени занимаются непонятно чем, иногда клепают очередную заплатку. Самое опасное в работе среди таких людей, это то, что очень быстро и незаметно можно опуститься до их уровня и увязнуть в этом болоте…
по моим наблюдениям движуха в компании зависит от ее размеров и результатов ее деятельности на рынке, которые определяют динамику ее развития, чем меньше компания и чем выше динамика, тем больше движухи, что логично :) перспективы в любой аутсорс компании как раз очень мутные по сравнению с «коробочными» компаниями, так как весь R&D в таких компаниях это просто ресурс и не более, сегодня нужен, наберем, да побольше и подешевле, а завтра не нужен, разгоним… + очень много в таких компаниях людей у которых знания обширные, но крайне поверхностные, то есть по-большому счету качественных знаний у них нет, что и не удивительно, так как за период времени «до года» работы в авральном в режиме сложно освоить какую-либо технологию на качественном уровне + такой уровень и не требуется в таких компаниях, там главное быстрее и дешевле, посмотрите на большинство вакансий таких компаний, требуется в основном всегда дешевая раб. сила…
про «очень удобный и комфортный бизнес центр» можно сказать только одно — все познается в сравнении, если до этого Вы работали в плохих условиях, то возможно в рексофте Вам покажется все сказкой, а насчет атмосферы, что-то очень большая текучка у этой замечательной семьи… одно слово — аутсорс, это как клеймо :)
теперь понятно… как говрится, век живи век учись, а помрешь все равно дураком… :) у меня просто никогда не возникало потребности так делать, так как всягда оставлял по-минимуму в хидере, только интерфейс, вся реализация, даже простые геттеры и сеттеры, в сипипишник, а то сегодня это простой геттер, а завтра не очень простой… да и члены класса так же полезно за pimpl спрятать… ну это уже у каждого свое кунг-фу…
конечно я не хочу сказать, что у с++ все чисто, у него все крайне нечисто, за это его многие и любят, не дает соскучиться… :) с другой стороны есть устоявшиеся идиомы и концепции программирования на с++, которые позволяют при их использовании избежать большинства граблей…
за терминологией мне кажется в стандарт или к страуструпу, как первоисточникам… хотя на мой взгляд оба эти манускрипта достаточно сложно перевариваемые, лучше почитать мейерса, саттера и александреску, у них все сжато и по делу, без лишней воды и с терминологией вроде все в порядке…
да епрст… Вы научитесь для начала корректно объяснять свои мысли при помощи устоявшейся терминологии, а не придумывать на ходу свои термины подкрепляя их не совсем корретными примерами…
«inline void f() {} обязательно означает, что код функции будет заинлайнен» я этого нигде не писал, будет заинлайнен код помеченный как inline решает компилятор, но это не значит что нужно использовать inline для внутренней линковки, когда для этого есть один из вариантов static… хотя я сейчас краем глаза глянул описание inline в стандарте и судя по описанию он действительно может использоваться в таком контексте, но мне непонятно зачем это делать если есть специальное средство…
относительно того, что static не сработает для методов класса… откуда Вы взяли такой пример?
«в стиле с++» это не только RAII, хотя конечно эта концепция одна из самых востребованных в контексте обработки ошибок при помощи исключений, да и не только… все описывать в рамках этой темы смысла нет, есть достаточное количество литературы по этому вопросу…
про исключение в деструкторе, это пример по-большому счету высосанный из пальца, опять же в здравом уме это никто делать не будет, на практике при работе с различными библиотеками я такого ни разу не встречал… java не c++ поэтому тут обсуждать нечего…
приведите пример того, что нельзя обернуть, пример с Builder я не догнал, так же как и с обязательной транзакционностью…
относительно фабрик, тут вообще книжки по плюсам не нужны, достаточно прочитать одну — паттерны проектирования от банды 4х, там кста помимо примеров на плюсах, есть примеры и на смолталк, если вдруг так смущают голые указатели в примерах…
Вам так кажется потаму что Вы знакомы с этой концепцией, а представьте человека, которые еще с ней не знаком, но решил почитать про паттерны, для него это будет лишняя на тот момент информации, которая может затруднить восприятие основной темы…
1 — все верно, дело во включении из разных юнитов, только кто в здравом уме и для чего это будет делать, если заранее известно, что такой код не «соберется» из-за повтороного определения из хидера без защиты от повторного включения???
2 — я же Вам написал, что inline != static, это разные ключевые слова с разным поведением, мало того что Вы используете их без понимая того для чего они нужны, так еще пытаетесь с умным видом доказать, что все ок, тем самым возможно вводя в заблуждение людей, которые читают эти комментарии… и с чего Вы вдруг решили, что static нельзя использовать для членов и методов класса???
3 — с шаблонами многое зависит от конкретного компилятора, его настроек и конкретной ситуации в коде… так что делать предположения тут дело неблагодарное… и причем здесь экспорт функций???
подучите все-таки матчасть, перед тем как вводить окружающих в заблуждение свои праведным напором, а то некрасиво как-то получается :)
в книжках просто стараются не нагружать читателя лишней информацией в примерах, по это причине могу использоваться примитивные конструкции… так же как например всегда опускается обработка ошибок для простоты примера кода… часто об это указывают в комментариях…
ну а по литературе тут вроде все давно все устаялось и не раз уже перечислялись все значимые книжки, основные наверно следующие:
очень странный пример честно говоря, так как во-первых все хидеры в с/с++ необходимо защищать от повторного включения соответствующими методами, тогда у Вас не будет проблем и в первом варианте… во-вторых ключевое слово static в данном случае говорит компилятору, что область видимости переменной ограничена модулем, в котором она объявлена, насколько я помню… термин статическая линковка первый раз слышу, но понятно о чем Вы, есть понятия внутренней и внешней линковки, которые завязаны как раз на область видимости переменной, тут Вы правы, static в данном примере используется для внутренней линковки… ну и в 3х, первый раз вижу чтобы для такого поведения использовали ключевое слово inline, так как оно предназначено для указания того, что вы хотите чтобы тело функции было вставлено в код вместо ее вызова, собственно из-за этого у нас и возникла легкая неразбериха…
что происходит в вашем примере:
1 — вы все верно описали, но тут проблема защиты от повтороного включения, которой нет
2 — линковщик не ругается по причине того, что он думает, что Вы хотите использовать код функции вместо ее имени, соотвественно проблем с дублированием имен нет… для поведения, которое Вы хотели необходимо использовать ключевое слово static…
3 — с темплейтами ситуация несколько похоже на предыдущую, но линковка будет внешняя
так что получается, что у Вас небольшая неразбериха, а не в с++ :)
у меня иногда создается впечатление, что так и есть… это я про обсуждения на тему exception safe code по всему интернету, ни одного вменяемого довода в пользу не использования исключений я не слышал, весь этот оверхед, который обычно сразу начинают вспоминать просто смешной, он настолько мал, что им можно без всяких сомнений пренебречь…
ну вот вспоминая проекты на с++ в которых я принимал участие, я не помню каких-либо проблем при использовании в качестве обработки ошибок исключений… а было в этих проетах всего полно, и легаси код без исключений на ретвалах, и старые либы а ля zlib, и COM-компоненты, как свои, так и чужие и различные библиотеки а ля boost/loki/atl… и никогда из-за этого никаких проблем не было, все аккуратно оборачивалось соответствующими обертками, которые использовали общий для проекта фрэйворк для обработки ошибок, построенный на исключениях и использовалось в основном коде… естественно для того чтобы все корректно работало, код должен писаться в стиле с++, а не в стиле с with classes как многие любят… :)
Да нет проблем, на обиженных воду возят… :) меня просто смутил ваш напор…
Я честно говоря не совсем понял что под inline подразумеваете Вы, можно просто пример небольшой?
Относительно переходя на личности, прошу прощения если не так Вас понял, видимо это у Вас просто манера общения такая… а классики вроде Страуструпа и не только, как раз прямым текстом и говорят, что макросы это зло.
В том-то и дело, что мест таких при программировании на с++ в стиле с++ нет, так же как и нет места в с++ «голым» указателям например…
Вы скорее всего опять мне не поверите, но сделать это гораздо проще, чем Вы пытаетесь представить… это просто требует стиля программирования в стиле с++ :)
относительно раскрутки стека, она понадобится только тогда, когда будет сгенерировано исключение, которое необходимо генерировать в исключительных ситуациях, при возникновении которых, ни о какой производительности уже речь не идет, так как надо обрабатывать такую ситуацию…
Какого рода дополнительные проверки не считая try/catch, который в минимальном варианте может распологаться на самом верху? Какого рода запреты оптимизаций, можно пример?
А что же Вы так любите задавать глупые вопросы? :) Когда темлейты не инлайн может зависеть от многих факторов, начиная от реализации конкретного компилятора, его настроек и заканчивая кодом конкрентного темплейта… и я не пойму с чего Вы вдруг приплели сюда линковку, если речь пока идет о препроцессинге и компиляции?
То что Вы считаете, что правильно используемые макросы упрощают понимание и написание код я уже понял и продолжать спорить с Вами смысла не вижу… Так же понятно, что Вы по какой-то причине заочно считаете себя умнее других, в том числе и Стауструпа, и Саттера, и Александреску и прочих Джосаттисов… ну да это со временем проходит… :) Сойдемся на том, что Вы выбрали свой путь. Так же добавлю, что если в вашем коде так много, в частности, специализаций шаблонов, что Вам приходится как-то автоматизировать их набор, то скорее всего стоит задуматься о корректности используемого подхода для реализации задачи…
Вы не поверите, но не только видел исходники stl, boost, loki, mfc, atl, wtl, но еще и написал не мало кода с их использованием, и еще не меньше дебажил чужого кода используещего эти самые библиотеки, а вот судя по Вам, раз уж мы перешли на личности, не хватает опыта участия в крупных промышленных решениях, которые разрабатываются несколько лет, несколькими поколениями разработчиков… так вот отлаживаться и искать дефекты в коде напичканном макросами такого рода проектов занятие скажем так на любителя… И да, вот именно после этого, я категорически считаю, что мета-программирование в си++ всегда лучше, чем макросы.
мой комментарий относился скорее не конкретно к приведенному примеру, а к комментариям относительно того, что макросы повышают читабельность кода, являются как бы частью интерфейса и скрывают реализацию там где она явно не нужна…
относительно вашего смелого заявления, что «темплейты вообще-то по определению инлайн», хочу Вас огорчить, это не всегда так…
по поводу громоздкой непонятной конструкции с угловыми скобками и дублированием типов; Вы правда считаете, что сокрытие такой конструкции за волшебным макросом повысит читабельность и понимание кода? от дублирования длинных шаблонных типов хорошо помогает typedef, все остальное должно быть явно написано без каких-либо игр в прятки с макросами…
относительно «в си++ другого не дано» я вообще не понял… еще раз в с++ есть все необходимые языковые средства для замены макросов…
на примере PROTO_IFACE нужно оставить явную специализацию шаблона, а не городить макро-огород, часто используемые типа а ля An<D_iface> заменить коротким синонимом при помощи typedef…
конечно я не хочу сказать, что у с++ все чисто, у него все крайне нечисто, за это его многие и любят, не дает соскучиться… :) с другой стороны есть устоявшиеся идиомы и концепции программирования на с++, которые позволяют при их использовании избежать большинства граблей…
за терминологией мне кажется в стандарт или к страуструпу, как первоисточникам… хотя на мой взгляд оба эти манускрипта достаточно сложно перевариваемые, лучше почитать мейерса, саттера и александреску, у них все сжато и по делу, без лишней воды и с терминологией вроде все в порядке…
«inline void f() {} обязательно означает, что код функции будет заинлайнен» я этого нигде не писал, будет заинлайнен код помеченный как inline решает компилятор, но это не значит что нужно использовать inline для внутренней линковки, когда для этого есть один из вариантов static… хотя я сейчас краем глаза глянул описание inline в стандарте и судя по описанию он действительно может использоваться в таком контексте, но мне непонятно зачем это делать если есть специальное средство…
относительно того, что static не сработает для методов класса… откуда Вы взяли такой пример?
class X
{
void f();
};
static void X::f() {} // compilation error!
inline void X::f() {} // OK
для решения какой проблемы необходимо писать такой код?
относительно экспорта очевидно, но после непоняток с inline я решил удостовериться, не сочтите это за проявление высокомерия с моей стороны…
про исключение в деструкторе, это пример по-большому счету высосанный из пальца, опять же в здравом уме это никто делать не будет, на практике при работе с различными библиотеками я такого ни разу не встречал… java не c++ поэтому тут обсуждать нечего…
приведите пример того, что нельзя обернуть, пример с Builder я не догнал, так же как и с обязательной транзакционностью…
Вам так кажется потаму что Вы знакомы с этой концепцией, а представьте человека, которые еще с ней не знаком, но решил почитать про паттерны, для него это будет лишняя на тот момент информации, которая может затруднить восприятие основной темы…
2 — я же Вам написал, что inline != static, это разные ключевые слова с разным поведением, мало того что Вы используете их без понимая того для чего они нужны, так еще пытаетесь с умным видом доказать, что все ок, тем самым возможно вводя в заблуждение людей, которые читают эти комментарии… и с чего Вы вдруг решили, что static нельзя использовать для членов и методов класса???
3 — с шаблонами многое зависит от конкретного компилятора, его настроек и конкретной ситуации в коде… так что делать предположения тут дело неблагодарное… и причем здесь экспорт функций???
подучите все-таки матчасть, перед тем как вводить окружающих в заблуждение свои праведным напором, а то некрасиво как-то получается :)
ну а по литературе тут вроде все давно все устаялось и не раз уже перечислялись все значимые книжки, основные наверно следующие:
www.ozon.ru/context/detail/id/2381848/
www.ozon.ru/context/detail/id/1273200/
www.ozon.ru/context/detail/id/2342923/
www.ozon.ru/context/detail/id/1224782/
www.ozon.ru/context/detail/id/2610625/
www.ozon.ru/context/detail/id/2623946/
www.ozon.ru/context/detail/id/3960662/
www.ozon.ru/context/detail/id/85559/
www.ozon.ru/context/detail/id/2576269/
www.ozon.ru/context/detail/id/4751845/
что происходит в вашем примере:
1 — вы все верно описали, но тут проблема защиты от повтороного включения, которой нет
2 — линковщик не ругается по причине того, что он думает, что Вы хотите использовать код функции вместо ее имени, соотвественно проблем с дублированием имен нет… для поведения, которое Вы хотели необходимо использовать ключевое слово static…
3 — с темплейтами ситуация несколько похоже на предыдущую, но линковка будет внешняя
так что получается, что у Вас небольшая неразбериха, а не в с++ :)
ну вот вспоминая проекты на с++ в которых я принимал участие, я не помню каких-либо проблем при использовании в качестве обработки ошибок исключений… а было в этих проетах всего полно, и легаси код без исключений на ретвалах, и старые либы а ля zlib, и COM-компоненты, как свои, так и чужие и различные библиотеки а ля boost/loki/atl… и никогда из-за этого никаких проблем не было, все аккуратно оборачивалось соответствующими обертками, которые использовали общий для проекта фрэйворк для обработки ошибок, построенный на исключениях и использовалось в основном коде… естественно для того чтобы все корректно работало, код должен писаться в стиле с++, а не в стиле с with classes как многие любят… :)
Я честно говоря не совсем понял что под inline подразумеваете Вы, можно просто пример небольшой?
Относительно переходя на личности, прошу прощения если не так Вас понял, видимо это у Вас просто манера общения такая… а классики вроде Страуструпа и не только, как раз прямым текстом и говорят, что макросы это зло.
В том-то и дело, что мест таких при программировании на с++ в стиле с++ нет, так же как и нет места в с++ «голым» указателям например…
То что Вы считаете, что правильно используемые макросы упрощают понимание и написание код я уже понял и продолжать спорить с Вами смысла не вижу… Так же понятно, что Вы по какой-то причине заочно считаете себя умнее других, в том числе и Стауструпа, и Саттера, и Александреску и прочих Джосаттисов… ну да это со временем проходит… :) Сойдемся на том, что Вы выбрали свой путь. Так же добавлю, что если в вашем коде так много, в частности, специализаций шаблонов, что Вам приходится как-то автоматизировать их набор, то скорее всего стоит задуматься о корректности используемого подхода для реализации задачи…
Вы не поверите, но не только видел исходники stl, boost, loki, mfc, atl, wtl, но еще и написал не мало кода с их использованием, и еще не меньше дебажил чужого кода используещего эти самые библиотеки, а вот судя по Вам, раз уж мы перешли на личности, не хватает опыта участия в крупных промышленных решениях, которые разрабатываются несколько лет, несколькими поколениями разработчиков… так вот отлаживаться и искать дефекты в коде напичканном макросами такого рода проектов занятие скажем так на любителя… И да, вот именно после этого, я категорически считаю, что мета-программирование в си++ всегда лучше, чем макросы.
относительно вашего смелого заявления, что «темплейты вообще-то по определению инлайн», хочу Вас огорчить, это не всегда так…
по поводу громоздкой непонятной конструкции с угловыми скобками и дублированием типов; Вы правда считаете, что сокрытие такой конструкции за волшебным макросом повысит читабельность и понимание кода? от дублирования длинных шаблонных типов хорошо помогает typedef, все остальное должно быть явно написано без каких-либо игр в прятки с макросами…
относительно «в си++ другого не дано» я вообще не понял… еще раз в с++ есть все необходимые языковые средства для замены макросов…
на примере PROTO_IFACE нужно оставить явную специализацию шаблона, а не городить макро-огород, часто используемые типа а ля An<D_iface> заменить коротким синонимом при помощи typedef…