Как понимается конструкция С++ по правилам этого языка
Надо С увеличть на единицу и вернуть СТАРОЕ (т.е. не увеличенное) значение
Впервые с зыком С++ я столкнулся почти 15 лет назад (почуствуйте какой стаж :))) начав работать на Turbo C++. Тогда из доступной литературы по объектно-ориентированному программированию у меня было очень хорошее (как мне тогда казалсь) руководство по ООП на Turbo Pascal 5.5.
В определенном смысле это было очень правильное руководство, на нескольких простых примерах показывалось, как использование наследования и инкапсуляции позволяет легко работать с разнообразными данными придавать им удобную структуру.
И в то время это казалось очень правильным и полезным (правда та реализация С++ отличается от современного стандарта как небо и земля). Какие-то сомнения пришли гораздо позже.
В частности, первые из них стали приходить при попытках использовать С++ для написания пользовательсвого интерфейса в форточках. Причем аналогичные проблемы в то время были почти у всех. Достаточно просто посмотреть сколько лет прошло между распространением С++ и форточек и появлением сколько-нибудь нормальных библотек классов для С++.
То решение (MFC), которые было предожено, выглядело явным уродством и не зря его в шутку называли Micro$oft Frustration Classes. То, что получалось уже не было нормальным текстом на С++, а представляло из себя уродливое нагромождение непонятных макросов.
Со временем пришло понимание, что на С++ иначе просто нельзя !!! Средства, изначально заложенные в сам язык, настолько негибки и жестки, что реализовывать системы, требующие гибкости на С++ было крайне тяжело и постояннно приводило к кривым способам (т.е. это бага а фича :)).
Давайте посмотрим на истоки возникновения С++ и попытаемся проследить мотивацию г-на Страуструпа. Как известно он для своей диссертации написал на языке Симула программу расчета данных.
Причем программа была написана очень быстро и легко, что весьма порадовало Б.С. Но вот дальше обнаружилось, что скорость работы этой программы крайне мала. Как говорят, ее не хватало даже для того, чтобы насчитать необходимые данные к моменту защиты дисертации.
Эффект этого произвел на (неокрепшие :)) мозги г-на Страуструпа был ужасен. Но вместо визита к психотерапевту он решил создать свой язык, который бы совмещал в себе высокую скорость разработки (от Симулы) и высокую скорость выполнения (от С).
Т.е. была поставлена задача написания языка, во-первых, объектно-ориентированного (в понимании Б.С.), а во-вторых, очень эффективного (в плане скорости выполнения скомпилированного кода).
Исходя из последнего было сразу заявлено "Вы не платите за то, чем не пользуетесь".
Кроме этих требований, также была поставлена задача облегчить переход для программистов на С к новому языку. Также хотелось сделать язык таким, чтобы компилятор мог сразу же находить все возможные ошибки (а для языка С позвать функцию с неправильными параметрами - это легко и просто).
Итак были сформцулированы следующие цели:
Язык должен быть объектно-ориентированным.
Язык должен быть эффективным.
Язык должен быть таким, чтобы программисты на С могли легко на него перейти.
Компилятор должен находить все возможные ошибки
Итак, давайте посмотрим, а что же получилось в результате.
Ну, местами (там где про stl и бред) от автора самого попахивает бредом. Столь важно ли, как называются методы? Один раз прочитал в мануале и всё. Рассматривать это как недостаток смешно.
Я тоже не люблю плюсы, но это единственный компилируемый язык, который я более/менее умею применять. А вообще, вы все и сами знаете, какой язык лучший --==^_____^==--
> Т.е. всего один символ в описании параметра может привести к очень большим затратам на создание и уничтожение вот этих временных объектов. А если это достаточно "тяжеловесный" объект или данная операция проводится в цикле, то затраты могут оказаться очень большими.
А если вместо if написать of то программа вообще не соберётся. Как страшно жить!
> Мне как-то пришлось искать почему программа, написанная аспирантом ф-та ВМиК МГУ падает через пару недель работы (она должна была работать на сервере месяцами). Именно по этой самой причине - копирование и уничтожение объектов при хранении объектов в контейнерных классах.
И что? Это написано даже в "с++ для чайников". Глупо сваливать что-то язык, если ты тупо об этом не знал.
Без него в С++ и жабе куда спокойнее. Не нужно молиться и приносить жертвы богам, когда меняешь базовый класс в гигантской иерархии, которая успела на нем вырасти. Есть и другие проблемы.
> Причина в том, что язык С++ крайне сложен и запутан, несет в себе множество мест, где люди совершают ошибки. Прямо такое море граблей, заботливо прикрытах травкой - идешь себе, идешь и вдруг - БАЦ ! Прямо по лбу !.
Претендует на серьёзную статью в духе Аналитиков Лора.
Что там Геббельс говорил? Тот кто критикует должен быть готов САМ занять место критикуемого. Иначе это не критика а клевета.
Это что-ж получается, Геббельс прав?!
PS. Никому не возбраняется создать свой язык. А вот если люди всё равно будут предпочитать C++, или (о боже!) Фортран, значит ничего не попишешь - сам дурак. В том смысле, что жизнь показала, что Страуструп и Степанов все же умнее.
PS2. Че-то последнее время мне С++ тоже не нравится. Нутром чую, что программы можно писать разика в два короче. Но альтернативы пока нет...
Я однажды написал одну ресурсоемкую программу для физических расчетов, сперва на С++, потом, когда меня не устроиле скорость работы, на С. Начало считаться быстрее в 10 раз.
Ко мне один раз пришёл одногруппник, у него медленно считалось. Я почитал, поржал, заменил передачу параметров по значению на передачу по ссылке, ещё по мелочи пооптимизировал, по-моему раз 1000 выиграл. Ради интереса попрофайлил, чуток потюнил структуру одну, чтобы с кешем хорошо работала, получил ещё раза 2 кажется, дальше было лень, и так полсекунды вместо получаса считала.
>> Без него в С++ и жабе куда спокойнее. Не нужно молиться и приносить жертвы богам, когда меняешь базовый класс в гигантской иерархии
>Не надо делать гигантских иерархий.
Да, в этом ты прав. Order унаследовать от Serializable<Order>, Person унаследовать от Serializable<Person>. После этого остается всего-навсего вынести всю сериализационную логику из cpp файла в h файл в виде шаблона и возрадоваться тому что в проекте все стало зависеть от всего.
совершенно верно написано в статье. Плюсы мерзость и точка. И они скоро сдохнут или останутся в мизерном количестве. Щас на нем много студиозного быдла, которые думают, что они будут грести на этом убожестве бабки. Хрена с два. Плюсатники одни из самых низкооплачиваемых, конкурируют только с пыхпыховцами, да от последних пользы больше и работают продуктивнее, чем плюсатное быдло.
>Да, в этом ты прав. Order унаследовать от Serializable<Order>, Person унаследовать от Serializable<Person>. После этого остается всего-навсего вынести всю сериализационную логику из cpp файла в h файл в виде шаблона и возрадоваться тому что в проекте все стало зависеть от всего.
Да, именно так и делай всегда. И почаще пиши о том, как ты неавидишь шаблоны и лично Страуструпа.