Я нашёл те километры текста, где рассказывается почему C++ говно.
http://yosefk.com/c++fqa/
Я сейчас не пытаюсь сказать, что C++ говно, это слишком провакационно и не правда. Просто прежде, чем заниматься им надо кое-что понять. Не стоит пытаться его учить только потому что якобы все используют его и он всем нужен (мне вообще кажется, что C++ форсируют).
Важно понимать, что C++ как и C это оболочка над ассемблером, позволяющая делать тривиальные вещи немножко проще, например:
[list:q1jmekx6]
[*:q1jmekx6]создавать и вызывать функции
на x86 ассемблере это выглядит так:
[code:q1jmekx6]calling_routine:
push local_variable
call function
function:
push bp ; save pointer to area of stack used by caller
mov bp, sp ; set up pointer for called
sub sp, something ; make some local space for local vars
; ... do everything....
nop
nop
mov sp, bp ; undo all the local vars and prepare to ret
pop bp ; retrieve pointer to old area of
; stack for caller
ret xxx ; return clearing xxx bytes of parameters sent[/code:q1jmekx6]
на C немножко проще:
[code:q1jmekx6]void function( int var )
{
// ... do everything....
}
function( local_variable );[/code:q1jmekx6][/*:m:q1jmekx6]
[*:q1jmekx6]делать математику, особенно операции с плавающей запятой и сравнение таких чисел[/*:m:q1jmekx6]
[*:q1jmekx6]контроль над потоком кода, это if/while/do/for/case и другие шняги[/*:m:q1jmekx6][/list:u:q1jmekx6]
На MASM32 есть макросы упрощающие создание/вызов функций (invoke и proc), также .if есть, можно даже на месте родить строку, вместо того чтобы писать в .data сегмент (макрос $str), но с математическими операциями всё равно тяжко, особенно с FPU.
То есть, при программировании на Ц, надо учитывать, что это нифига не "High Level Language". В нём надо быть столь же внимательным как когда программишь на ассемблере. К сожалению это заводит новичков в глубочайшее заблуждение. Не понимают, что они пишут код, который процессор будет обрабатывать практически непосредственно. Современная вычислительная техника усложнена до безобразия. Процессор [url=http://lurkmore.to/x86:q1jmekx6]x86[/url:q1jmekx6] состоит из костылей чуть менее чем полностью. Необходимо знать множество тонкостей, очень много. Настолько много, что в голову это всё сразу не лезет и элементарно не понять, что если в переменной unsigned int записать ноль, потом отнять один, будет число 4294967296 (причём неточно, может быть что угодно на самом деле, в зависимости от архитектуры). Что если ты выделил отрезок памяти, записал немножко за её пределами, а ничего пока не произошло — это не значит, что прога не будет делать Segmention Fault в самых непредсказуемых местах. Такую ошибку чертовски легко сделать и так же чертовски трудно найти, если ошибка в одном месте, а Seg. Fault произходит в другом месте, из-за кода который повредил память самому себе. Казалось бы высокоуровневый язык программирования, а все эти тонкости описаны подробно при изучении ассемблера, только почему-то опускаются при изучении Ц. Поэтому ещё раз напомню, что перед вами не совершенной другой язык программирования, а удобная оболочка перед ассемблером.
Дело в том, что ассемблер — это очень простой язык программирования, в нём всего 50 команд, очень простых. Их легко запомнить все наизусть. И Ц тоже простой (именно синтаксис, библиотеки POSIX и WinAPI32 как-бы отдельно). Так вот из-за этой простоты он в то же время очень сложный. Рассмотрим примерчик (не самый хороший, но надеюсь что пойдёт). Чем проще расчитать переходной процесс в электрических цепях? На бумажке и пользуясь калькулятором, который умеет операции плюс, минус, деление, умножить и другие, или на MultiSim/SPICE/Proteus? Пользуясь калькулятором мы можем простыми операциями делать сложные операции, например, вычислить расстояние между двумя точками [img:q1jmekx6]http://goo.gl/cmyRR[/img:q1jmekx6] состоит из четырёх простых операций, а в крупных математических пакетах типа wxMaxima есть отдельная функция для этого. Также и в Ц: пишешь кучу команд, чтобы сделать что-то сложное. В этот момент должны быть очевидны достоинства и недостатки обеих способов. В случае калькулятора ты обладаешь большими знаниями, умеешь сделать расчёт и понимаешь почему и как, можешь вмешиваться в промежуточные этапы вычислений, вывести зависимость (получить формулу для быстрого вычисления при изменения входных параметров), и вообще ты труъ. В случае MultiSim ты школоло, вольтметр будет показывать какие-то произвольные числа на сложном несинусоидальном сигнале и не можешь проверить достоверность показаний. Хорошо знайте свои цели и возможности. Ц может выучить либо задрот, либо профессионал своего дела.
А вот OOP (объектно-ориентированное программирование) необходимо рассмотреть отдельно. Суть его в абстракции, объектном разделении и прочая псевдонаучная дребедень. Что тут такого? Во-первых, Ц — это низкоуровневый статический процедурный язык программирования, к нему тяп-ляп прилепили OOP и гордо назвали этого монстра Ц++, во-вторых, эта реализация... мягко сказать, неудачная. Когда пишешь OOP на Ц++, допустим, используешь там полиморфизм, классы, шаблоны, stl, и прочий треш, замечаешь, что ты пишешь не код, а какой-то криптошифр. Выглядит это очень страшно, даже для опытного программиста: [url:q1jmekx6]http://yosefk.com/c++fqa/defective.html#defect-7[/url:q1jmekx6]. Другими словами эти сущности усложняют и так уже сложный язык программирования для изучения и использования.
Я перечислю задачи, которые я делал на Ц, которые было легко и удобно делать: обрабатывать данные, там где необходима скорость; писать игры, чтоб игралось без лагов; драйвера; микроконтроллеры; и подобное. Задачи на Ц, которые делать неудобно и наверное не стоит: обработка/интерпретирование текста (если конечно ты не пишешь lua); графический интерфейс; работа с базами данных — для этих задач я бы лучше прилепил какой-нибудь скриптовый язык типа TCL/Lua. То есть программишь на двух языках, в зависимости от задачи, как например это сделано в играх часто: движок написан на Ц, а игровая логика и интерфейс на чём-нибудь скриптовом (World of Warcraft, Quake 3 Arena, ...).
Если увереность в себе всё ещё осталась, то вперёд. Искренне желаю удачи и успеха в освоении :>
