coodan

На мой взгляд, перспективность java сильно преувеличена. Да, была перспективна. А сейчас мы наблюдаем ее медленную смерть. Тревожным звоночком является то, что уже не на каждом компьютере она запускается без танцев с бубном. А ведь это было залогом популярности. И возникает вопрос - зачем тогда привязываться...

Если нравится С++, если Вы его понимаете и он Вам близок - обязательно продолжайте. Он ведь как раз для таких людей.

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

Думаю, слова о множественных парадигмах и есть ключ, к тому, к чему Вы стремитесь. Ведь Вас интересуют новые возможности?

Конечно, Вам стоит изучить подходы, связанные с generic programming. Boost в значительной степени основан на этой парадигме. Действительно, там, как и с паттернами вообще, возможны трудноулавливаемые ошибки. Но этот подход сильно меняет суть и облик С++, поэтому может быть важен для Вас.

Начинать generic programming стоит с его основ - с того, чтобы по-новому взглянуть на STL и контейнеры. Effective STL, по-видимому, самая простая и хорошая книга об этом:
www.amazon.com/Effective-STL-Specific-Standard-Tem...

P.S. На конкретном простом примере. Когда мне понадобилась работа с графами, изучил вопрос и просмотрел библиотеки, которые обеспечивают данную функциональность. Некоторые из них заброшены не поддерживаются. Другие вроде бы и ориентированы на ООП, но их интерфейс производит впечатление какой-то запутанности, недостаточно ясного понимания, что порождает сомнения в цельности и безошибочности их реализации. Лучшим решением в этой области на тот момент, по моему мнению, оказалась библиотека boost::graph. Но это чистое обобщенное программирование, как оно есть. Без понимания того, что это такое, умения это использовать и на этом писать, делать там нечего. С ООП это не стыкуется вовсе. Это другое.

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

Раз уж вопрос задан - то никакую. Вам вообще не надо читать книги. Вас от чтения, очевидно, ломает :)

Здесь есть несколько аспектов, в котором Вы могли бы задать этот вопрос, оттого он может иметь несколько значений.

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

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

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

Чисто академический путь в наших условиях крайне проблематичен. Впрочем, наверное, в Вашем университете есть аспирантура. Если же рассмотреть вариант, когда Вы сохраняете академический интерес к проблеме и поддерживаете академические ценности (стремление к познанию вне практического применения полученных знаний, любовь к истине), но при этом работаете в практической сфере, то ответ становится не таким очевидным. Вы упоминали о тестировании софта. Эта работа непрестижна. Но тем не менее, очень важная - довольно избито, что тестирование сейчас лимитирует разработку. Довольно утомительная и однообразная работа. Бессмысленная при низкой квалификации разработчиков. Но, может так оказаться, что в силу дефицита тестировщиков, Вы, приложив к этому силы и отбрасывая все неквалифицированные коллективы, сможете найти место, где пишут код, который определенно стоит того, чтобы его отлаживать. Может так оказаться, что лучше быть мальчиком для битья у чемпиона по боксу, чем тренироваться с плохим тренером среди неумех.

Гадал на картах - не помогло. Кидал кости - тоже. Спросил ответа у звезд. Звезды интересуются - не потому ли, что Вы делите на 180? :)

А если пользователю инет отключат? :)))

Зачем изобретать велосипед, если уже есть комплекты разработки защищенных программ? :) А там и ключи с таймерами, и шифрование, и прочая мякотка - хочешь, хоть кусок кода в зашифрованное пространство пиши, чтобы как черный ящик работал - ничего в память не копировал, внутри ключа выполнялся и результаты выдавал :)

Может, brainfuck подойдет? :)))

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

Когда озадачивался графами, пришел к выводу, что boost::graph лучшее, хотя и небезупречное решение. Но если Вы сильно ориентированны ООП-подход, а generic programming вызывает трудности, то лучше поискать альтернативу, ориентированную на ООП.

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

Практичен ли С++ для говнокодерства? Нет. Он будет беспощаден. И в этой беспощадности его сила. Код, написанный идеально, будет работать идеально. Но где этот идеал? И сколько времени Вам понадобится, чтобы найти свое в С++ нуля?

Зачем играть в шахматы с гроссмейстером, если можно легко обыгрывать соседей? И что даст Вам такая игра? К чему Вы стремитесь? На эти вопросы можете ответить только Вы.

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