Здравствуйте, FR, Вы писали:
FR>Здравствуйте, carpenter, Вы писали:
C>>ну и еще тогда добавлю — язык собственно не так важен , а вот понимание
FR>В случае C++ важен. Но не доскональное знание всех тонкостей языка, а практика работы FR>пусть и с ограниченным подмножеством. C++ не прощает ошибок в мелочах.
Что подразумевается под "практикой работы"?
Не забывать освобождать ресурсы руками и проверять пойнтеры на null?
Здравствуйте, StandAlone, Вы писали:
FR>>В случае C++ важен. Но не доскональное знание всех тонкостей языка, а практика работы FR>>пусть и с ограниченным подмножеством. C++ не прощает ошибок в мелочах.
SA>Что подразумевается под "практикой работы"?
Под практикой понимается что человек не задумываясь может писать правильный код на C++.
SA>Не забывать освобождать ресурсы руками и проверять пойнтеры на null?
Угу это тоже, только таких мелочей в C++ очень много.
Здравствуйте, FR, Вы писали:
FR>Под практикой понимается что человек не задумываясь может писать правильный код на C++.
А "правильный код" это какой?
По Шилдту, Мейерсу, Саттеру, Александреску, Элджеру, или...?
Не секрет, что одну и ту же задачу можно решить множеством путей — С с классами, обобщенно, с использованием STL...
какой подход будет "правильным кодом"?
FR>Угу это тоже, только таких мелочей в C++ очень много.
Например? Этих мелочей можно легко избежать, юзая ссылки и raii-врапперы.
Что еще остается?
Препроцессор?Переполнения?
P.S. Мне действительно интересно, готовлюсь к интервью по С++
Здравствуйте, FR, Вы писали:
FR>Под практикой понимается что человек не задумываясь может писать правильный код на C++.
А "правильный код" это какой?
По Шилдту, Мейерсу, Саттеру, Александреску, Элджеру, или...?
Не секрет, что одну и ту же задачу можно решить множеством путей — С с классами, обобщенно, с использованием STL...
какой подход будет "правильным кодом"?
FR>Угу это тоже, только таких мелочей в C++ очень много.
Например? Этих мелочей можно легко избежать, юзая ссылки и raii-врапперы.
Что еще остается?
Препроцессор?Переполнения?
Здравствуйте, StandAlone, Вы писали:
SA>А "правильный код" это какой? SA>По Шилдту, Мейерсу, Саттеру, Александреску, Элджеру, или...? SA>Не секрет, что одну и ту же задачу можно решить множеством путей — С с классами, обобщенно, с использованием STL... SA>какой подход будет "правильным кодом"?
Любой из них, главное уметь писать чтобы работало, и уметь быстро исправлять возникающие ошибки.
FR>>Угу это тоже, только таких мелочей в C++ очень много.
SA>Например? Этих мелочей можно легко избежать, юзая ссылки и raii-врапперы.
Не всегда легко, библиотеки и API часто используют голые указатели. Враперы тоже нужно уметь написать
SA>Что еще остается?
Море вещей.
Во первых классы, конструкторы, конструкторы копирования, деструкторы (виртуальность и исключения), перегрузка функций и операторов, наследование и множественное наследование, динамическое создание классов и срезки и т. п..
Дальше вкратце:
Исключения.
Шаблоны.
STL. (Как пример в обычном std::vector обычный resize может привести к многочасовой отладке)
Указатели, ссылки, управление памятью, преобразования типов.
Плюс заморочки унаследованные от си, плюс теперь нередко требуется знание boost.
SA>Препроцессор?Переполнения?
Это тоже.
SA>P.S. Мне действительно интересно, готовлюсь к интервью по С++
SA>А "правильный код" это какой? SA>По Шилдту, Мейерсу, Саттеру, Александреску, Элджеру, или...? SA>Не секрет, что одну и ту же задачу можно решить множеством путей — С с классами, обобщенно, с использованием STL... SA>какой подход будет "правильным кодом"?
Я я ... можно я
Я могу сказать что для меня правильный код —
1 — код , который логически понятен — т.е. например функции называються так как то что они делают
классы делают то что должны и содержат подклассы или объекты в себе , которые логически должны быть .
обмен данными между обьектами понятен и логичен.
2 — когда вдруг нужно добавить или убрать фичу — это сделать легко — не нарушая целостности и
логичности программы .
3 — когда смотришь на свой код через год — не говоришь — какой му...к это писал
— а говоришь аяяй какой молодец
а всякие темплэйты бусты и всякая перегруженная фигня — это всего лишь средство ...
найти багу с невалидным поинтером в 10 раз легче , чем добавить фичу в монструозный проект
в котором все намертво скреплено плохой архитектурой
Здравствуйте, FR, Вы писали:
FR>Не всегда легко, библиотеки и API часто используют голые указатели. Враперы тоже нужно уметь написать
Все уже написано до нас, smart pointerы точно
FR>Во первых классы, конструкторы, конструкторы копирования, деструкторы (виртуальность и исключения), перегрузка функций и операторов, наследование и множественное наследование, динамическое создание классов и срезки и т. п..
Угу. Все то, о чем пишет Мейерс в своем мега-буке. Вопрос — в продакшен-коде это все вообще часто бывает нужно? Особенно для миддла?
Срезка там, например, или виртуальное наследование с завязкой на порядок инициализации объектов-членов класса?
"чтобы работало, и уметь быстро исправлять возникающие ошибки."-- ошибки, случаем, не от использования ли исключений в конструкторах лезут?
Или неумеренной перегрузки операторов +,-,<<, etc.?
FR>Исключения.
В какой момент и кем удаляется объект исключения?
FR>STL. (Как пример в обычном std::vector обычный resize может привести к многочасовой отладке)
Угу. Саттер, "Новые сложные задачи...". Такое впечатление, что список весь из книг. А по рабочему коду?
FR>Указатели, ссылки, управление памятью, преобразования типов.
Ну вот это еще как-то можно отнести на C legacy. А ссылки-то, госсподи, с ними-то какие проблемы?
Здравствуйте, StandAlone, Вы писали:
SA>Все уже написано до нас, smart pointerы точно
Угу, только дьявол в C++ как всегда в деталях типа std::auto_ptr<MyClass>(new MyClass[10]).
FR>>Во первых классы, конструкторы, конструкторы копирования, деструкторы (виртуальность и исключения), перегрузка функций и операторов, наследование и множественное наследование, динамическое создание классов и срезки и т. п..
SA>Угу. Все то, о чем пишет Мейерс в своем мега-буке. Вопрос — в продакшен-коде это все вообще часто бывает нужно? Особенно для миддла?
Зависит от принятого стиля кодмрования. Если классы не используются или используются как POD типы не нужно, если же нет то гарантированно эти вопросы всплывут.
SA>Срезка там, например, или виртуальное наследование с завязкой на порядок инициализации объектов-членов класса? SA>"чтобы работало, и уметь быстро исправлять возникающие ошибки."-- ошибки, случаем, не от использования ли исключений в конструкторах лезут?
Ошибки в C++ лезут в основном из-за того что не учтено какое-то мелкое исключение из правил А С++ как раз язык почти целиком состоящий из таких исключений
SA>Или неумеренной перегрузки операторов +,-,<<, etc.?
Это фигня, но таких фигней слишком много
FR>>Исключения. SA>В какой момент и кем удаляется объект исключения?
Я работу не ищу
И предпочитаю создавать объекты исключения только по значению не динамически.
FR>>STL. (Как пример в обычном std::vector обычный resize может привести к многочасовой отладке) SA>Угу. Саттер, "Новые сложные задачи...". Такое впечатление, что список весь из книг. А по рабочему коду?
Я эту книгу не читал, просто перечислил где возможны проблемы, пример с вектором привел потому-что в свое время больно стукнуло по лбу, притом я в теории все знал, что не помешало посадить феерический баг. Плюс с вектором имеют подобные проблемы практически все начинающие.
FR>>Указатели, ссылки, управление памятью, преобразования типов.
SA>Ну вот это еще как-то можно отнести на C legacy. А ссылки-то, госсподи, с ними-то какие проблемы?
