Блог пользователя OSt

Автор OSt, 15 лет назад, По-русски

Всем привет. Продолжаю серию статей про любимый язык программирования.

На этот раз коснёмся вечного вопроса "Java vs C++" в масштабах промышленного программирования.

Хотя некоторые вещи касаются вполне и выбора языка на ранних стадиях обучения, в том числе некоторые вещи применимы и для выбора языка для олимпиад. Я собственно так и выбрал Java :)

Самым авторитетным для меня источником стала статья моего тренера - Федора Владимировича Меньшикова. Эта статья как раз была и написана, когда встал вопрос "Что изучать после Pascal" :)

PS: Все копирайты соблюдены. Статья публикуется с разрешения автора.



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

Небольшой обзор разницы идеологий языков далее.


Рассмотрим вопрос применимости языков для промышленного программирования -
создания программ в десятки и сотни тысяч строк кода.

Языки будем сравнивать по двум критериям:
1. Как известно, основное требование к программе - корректная работа.
Поэтому основным критерием сравнения будет "насколько язык располагает к
совершению ошибок."
2. Вторым фактором будет "насколько удобно писать на языке".


Критерий 1. Насколько язык располагает к совершению ошибок.
Ошибка 1.1. Обращение к чему-то несуществующему.

Когда происходит обращение к неизвестно чему, то и программа работает
неизвестно как. Скажем, в 255 случаях из 256 она может работать, а в 1
случае может сбоить. А ещё это "неизвестно что" может оказаться данными
другого модуля программы.

Ошибка 1.1.1. Обращение к несуществующему элементу массива.

Язык Ява, как и C#, гарантирует, что при индексации массива нельзя
обратиться к несуществующему элементу массива. Если обращение к
несуществующему элементу произошло, генерируется исключение.

Язык C++ унаследовал классические массивы от языка Си, а в языке Си
проверки при индексации массива не только отсутствуют, но и вообще
невозможны, поскольку в процедуры, например, не передаётся длина
обрабатываемого массива, только ссылка на его начало.

Однако C++ не заставляет пользоваться классическими массивами. На C++ можно
написать шаблон класса, имитирующего работу с массивом с проверкой
диапазонов. Всё различие будет заключаться в описании переменной:
StaticArray<int, 5> a;
вместо
int a[5];
а работа с таким "массивом" может происходить ровно тем же образом, как
работа с классическим массивом.

Я для себя такой шаблон написал, и подобные шаблоны используются в крупных
проектах, однако для чего-нибудь маленького вроде решения олимпиадной
задачи такой способ сделать язык безопасным не проходит - на написание
StaticArray никто не захочет тратить такое драгоценное на олимпиаде время.

Ошибка 1.1.2. Обращение к уже несуществующему объекту через указатель.

Язык Ява, как и C#, гарантирует, что объект не удаляется, пока к нему можно
обратиться через указатель. Поэтому обратиться к уже удалённому объекту
невозможно.

В языке C++ программист сам отвечает за удаление объектов, так что никто
ему не мешает создать два указателя на объект, через один указатель этот
объект удалить, а через второй потом поработать с тем местом, где объект лежал.

Однако C++ не заставляет пользоваться классическими указателями. В C++
можно написать шаблон класса, имитирующего указатель с проверкой отсутствия
обращений к объекту после его удаления. Ещё большую ценность представляет
класс так называемых "умных" указателей, которые сами удаляют объекты, на
которые указывают, как только исчезает последняя ссылка. Как и в случае с
массивами, всё различие в использовании такого шаблона будет в описании
переменной:
Ptr<MyClass> p;
вместо
MyClass *p;

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

Ошибка 1.1.3. Удаление объекта изнутри его самогО.

Как я уже упоминал, в Яве программист не может сам удалить объект, поэтому
проблемы нет. А в C++ программист сам отвечает за удаление объекта. Особый
случай - когда прямо или косвенно удаляется объект, в котором находится
исполнение. Проблема заключается в том, что после удаления объекта все его
поля являются недействительными, и после удаления самого себя нужно строго
выйти из процедуры, ни к чему больше не притрагиваясь. Как правило это не
так просто, если не знаешь, что ты себя удалил. Решением является в том
объекте, который провоцирует удаление, проверять, не в удаляемом ли объекте
сейчас находится поток управления. Решение работает, но такие проверки -
это, конечно, дополнительные усилия со стороны программиста.

Ошибка 1.2. Использование неинициализированных переменных.

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

В Яве, как и в C#, гарантируется, что все поля объекта при создании
зануляются. Если это int - значение 0, если boolean - false, если объект -
null.

В C++ зануления нет, и это очень опасно. Реально сталкивался с проблемой
невоспроизводимых ошибок. При одном состоянии памяти программа переходит в
состояние ошибки, при другом состоянии памяти замечательно работает. Ошибка
оказалась в отсутствии инициализации поля в одном (!) из двух конструкторов.

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

Как и в случае с прочими упоминавшимися возможностями, написание такого
переопределения оператора new дело не совсем тривиальное, и в маленьких
проектах вроде олимпиадных задач нет возможности тратить на это время.

Ошибка 1.3. Отсутствие удаления/закрытия ресурса.

Если по предыдущим пунктам могло сложиться впечатление, что Ява намного
лучше C++, то этот пункт будет скорее в пользу C++.

Как выглядят внутренности обычной процедуры обработки файла:
<открыть файл>
<читать и обрабатывать данные>
<закрыть файл>

Пока последовательность действий линейна, всё хорошо, открытый файл будет
закрыт. Но что если в ходе обработки файла случится исключение или будет
желание выйти через return из функции? Будет ли файл корректно закрыт?

В Яве для гарантированного закрытия таких ресурсов приходится операторы
<читать и обрабатывать данные> заключать в блок try-finally. На самом деле
не очень эстетично выглядит, а уж когда несколько переменных таким образом
гарантированно закрыть надо - тут уже синтаксис получается туши свет. И что
самое противное - ничто не обязывает программиста писать блок finally, так
что ничто не поддерживает систему гарантированного освобождения ресурсов.

В C++ в смысле освобождения ресурсов всё, наоборот, хорошо. Язык
гарантирует вызов деструкторов всех локальных объектов при выходе из
процедуры любым способом - и через return, и через исключение. Поэтому всё,
что нужно - это обернуть ресурс в объект, и в конструкторе объекта
прописать открытие ресурса, а в деструкторе - закрытие. И в тексте основной
процедуры не появляется никаких finally, и где бы этот объект не
использовался, везде при любых обстоятельствах освобождение ресурса
гарантируется.

Ошибка 1.4. Неожиданные для программиста свойства языка.

Язык C++ имеет ряд особенностей, из-за которых программы могут работать не
так, как ожидает программист, а чтобы они работали как надо нужно что-то
неочевидное изменить. Такие особенности просто нужно знать и учитывать.
Проблема в том, что люди, начинающие писать на C++, этих особенностей не
знают, и узнаЮт об этих граблях только через некоторое время. Существуют
даже книжки о таких граблях. Мне нравится книга Скотта Мейерса (он же
Майерс, он же Мэйерс) "Эффективное использование C++".

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


Критерий 2. Насколько удобно писать на языке.

Возможность 2.1. Циклический импорт.

Иногда два класса зависят друг от друга. В компиляторе может быть, скажем,
такая ситуация: в выражении (скажем, при приведении к какому-то типу) может
встречаться тип, а в типе (скажем, в описании диапазона индексов массива)
может встречаться выражение. Первый должен вызвать методы второго, а второй
- методы первого. Возникает вопрос, кто кого должен импортировать.

В Яве этот вопрос решается просто - циклический импорт разрешён, классы
друг друга увидят. В C++ циклический импорт запрещён, кого-то нужно
объявлять первым. Решение на C++, конечно же, существует и заключается в
наследовании от интерфейсного класса с чисто виртуальными функциями, но как
заумно это звучит, так же плохо это и выглядит, хотя замечательно работает.

Возможность 2.2. Библиотеки шаблонов структур данных.

Как C++, так и Ява, в отличие от Паскаля, оба содержат библиотеки с
шаблонами вроде std::vector, std::map и т.п. Например, std::map - это
аналог массива, только индексы не обязаны быть целыми числами, достаточно
уметь сравнивать две переменные типа ключа на меньше. Эффективная
реализация подобных структур данных для каждого конкретного случая
потребовала бы от программиста титанических усилий - а тут всё уже готово,
бери и пользуйся.

К сожалению, стандартные контейнеры C++ поступают в духе Си и не
обеспечивают никаких проверок диапазонов и т.п. К счастью, существует
бесплатно распространяемая библиотека STLPort, где можно включить режим
проверок. Но её нужно скачивать и устанавливать, с известными компиляторами
она не поставляется.

А ещё очень хочется оторвать руки тому, кто в C++ у std::vector (массив с
возможностью роста) значение функции size() сделал беззнаковым числом.
После этого цикл
for (int i = 0; i < a.size(); i++)
приходится записывать или как
for (int i = 0; i < (int)a.size(); i++)
или как
for (std::vector<int>::size_type i = 0; i < a.size(); i++)
или получать предупреждение компилятора о сравнении числа со знаком и числа
без знака.

Возможность 2.3. Исключения.

Как C++, так и Ява, в отличие от Оберона, оба поддерживают исключения.

Что должен сделать компилятор при обнаружении ошибки? Сообщить о ней - и на
этом в принципе миссия завершена. Традиционный подход в простеньком
компиляторе - после выдачи ошибки просто завершить программу с помощью
средств вроде exit() C++, System.exit() Явы или halt() Паскаля. А что если
компилятор встроен в редактор? Всё-то он не должен выносить, должна
завершиться только стадия компиляции. Вот тут как раз исключения и могут
помочь. Они позволяют из процедуры выдачи ошибки перескочить на самый
верхний уровень без дополнительного кода в процедурах синтаксического
анализа. Помнится, я писал компилятор на Обероне, так там раз 200 в
синтаксическом анализаторе встречалась строка IF error THEN EXIT; END; Вот
какие ужасы могут твориться в языке без поддержки исключений.


Вот краткий обзор возможностей языков. В плане обеспечения надёжности для
больших проектов C++ и Ява практически равны. Для надёжных набольших
проектов Ява, похоже, подходит лучше. А для тех, кто считает, что пишет
только правильные программы, в которых нет ошибок и которые не нуждаются в
отладке, безусловно, подходит "чистый" C++. :-)

PS:

Прошу не оценивать данную статью, ибо за её качество ответственность несёт сам автор.

Я не имею никакого права получать за неё + или - ,т.к. она не моя. 

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

  • Проголосовать: нравится
  • 0
  • Проголосовать: не нравится

15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Я с Java увы не знаком, "промышленное" ПО пишу на C#, а олимпиады на С++. Но речь не об этом.

Чтобы писать промышленное ПО на С++ нужно иметь опыт.. и очень неплохой опыт. И знать множество граблей, на которые наступать нельзя. На работе есть товарищ, который как раз пишет довольно серьезные вещи на С++. Он выдвинул идею о том, что можно писать все на чистом С. И даже то, что С не поддерживает ООП как таковое, его не страшит. Главный довод в том, что граблей намного меньше и все плюшки, которые дает Объектноориентированный подход можно самому  обеспечить. Мне сложно с этим согласиться. 

Поэтому интересно есть ли из участников люди, которые разделяют любовь к обычному С в промышленной разработке?

  • 15 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится
    Да все можно написать на чистом C. Но вот вопрос - что главное в промышленном программировании? Правильный ответ достижение максимального результата при минимуме затрат. Вы сможете достичь минимума затрат времени и денег используя чистый C? Я готов утверждать что в 90% случаев чистый С или даже С++ яве проиграет. Хотя бы потому что программист на С дороже. Хотя бы потому что профессиональных программистов с опытом разработки на С меньше. И хотя бы потому что количество написанных библиотек и фреймворков для Java больше.
    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      Александр Васильевич, я полностью согласен с вашими доводами, но вопрос не в том, можно ли написать на С, сколько это стоит и как много времени это займет. Я хотел узнать, есть ли люди, которые практикуют С в разработке софта, среди участников дискуссии 
  • 15 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится
    UnderFelixAbove

    Ну GNOME вон на чистом С написан. И ничо, пилят, не загибаются.
    KDE - на С++. Тоже живут. :)

    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      Иван меня интересовал немного другой вопрос(см. ответ a.v.morozov'у). А то, что люди пишут на С довольно успешно - это не секрет.
15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится
Я считаю, что в рамках промышленного программирования некорректно сравнивать два языка только с точки зрения обработки ошибок и удобства написания программ. Следует также уделять внимание таким важным аспектам, как кроссплатформенность, производительность и наличие библиотек и фреймворков для языка.
  • 15 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится
    Полностью согласен. Какое-то не совсем корректное сравнение получилось...
15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Интересная статья. Но, если я не ошибаюсь, в STL как раз предусмотрена проверка выхода за границы. Я много раз видел исключение "vector(string) subscript out of range". 

По поводу разверов в unsigned int, то да, борода. Однако строчка 

#define sz(v) (int((v).size()))

полностью решает эту проблему.

  • 13 лет назад, # ^ |
      Проголосовать: нравится +1 Проголосовать: не нравится

    Можно делать так: for (size_t i = 0; i < a.size(); i++) И это решает проблему, не теряя смысла.

    • 13 лет назад, # ^ |
        Проголосовать: нравится +1 Проголосовать: не нравится

      Я уже подумываю — а не убрать ли мне сей пост в черновики... Года не проходит, как его обязательно кто то "воскресит"...

      • 13 лет назад, # ^ |
          Проголосовать: нравится +4 Проголосовать: не нравится

        Зачем убирать в черновики такой хороший пост?

        • 13 лет назад, # ^ |
            Проголосовать: нравится +5 Проголосовать: не нравится

          Когда писался этот пост сайт только начинал расти, я чувствовал, что могу быть чем то полезен. Но в результате огрёб столько не приятных эмоций (и всё по делу), что вспоминать стыдно. Прям как смотришь на свои программы, которые писал 5-6 лет назад :-)

          Если пост даже с моими подчас дерзкими комментариями всё ещё может быть полезен (как минимум комментариями других людей), то можно и не убирать.

          • 13 лет назад, # ^ |
              Проголосовать: нравится 0 Проголосовать: не нравится

            Думаю, что пост все еще полезен :)...Я вот узнал некоторые интересные вещи, прочитав его и комментарии к нему.

15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится
Так же надо учесть, что Java и C++ даже создавались для разных целей.
15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Вот ответ из письма-ответа на некоторые комментарии. Автор предупредил, что больше отвечать не будет.



Но, если я не ошибаюсь, в STL как раз предусмотрена проверка выхода за
границы. Я много раз видел исключение "vector(string) subscript out of range".

Ошибаетесь. В Стандарте описано, когда производится проверка и выдача исключения std::range_error. Никогда при применении []. У строк - скажем, в случае substr(). У векторов - в случае at().

По поводу разверов в unsigned int, то да, борода. Однако строчка #define sz(v) (int((v).size()))
полностью решает эту проблему.

Это для олимпиад такое решение подходит. А если в языке int 32-разрядный, а указатели 64-разрядные?..




1) Заголовок статьи совершенно не соответствует содержанию. Предлагаю
"Java vs C++ для олимпиадного программирования".

Как раз программу в 100 (пусть и в 500) строк можно держать в голове и написать идеально. Написание программы в 100 тыс строк без проверок, встроенных в язык/библиотеки требует колоссальных усилий. Я бы не хотел писать на Perl ничего свыше 1000 строк.

3) StaticArray писать не надо. Есть готовый boost::array. А на самом
деле std::vector подходит почти всегда. Но это только в "промышленном"
программировании.

std::vector не подходит по причине отсутствия проверок диапазонов. boost::array тоже - разрабатывался прежде всего из соображений скорости. Так что когда нужен аналог проверок при каждом обращении к массиву (как в Яве) - приходится писать своё.

4) Времена жизни объектов надо знать. И создавать объекты в строгих
иерархиях времён жизни. Для некоторых особо сложных случаев есть
boost::shared_ptr.

Особенно круто boost::shared_ptr помогает в засорении динамической памяти в случае циклических ссылок.

6) Все типы, кроме элементарных правильно себя инициализируют. Если у Вас
слишком часто используются элементарные типы в "промышленных" условиях,
ищи по теме "одержимость элементарными типами".

class Class {
int field;
};

Кто проинициализирует поле field? Никто! Нужно не забыть в каждом конструкторе! Или Вы предлагаете вместо int использовать обёртку - класс, содержащий одно поле типа int?

9) Про "циклический импорт" см
http://alexanderchuranov.com/cc-examples/circular/ и никаких наследований.

А если тело функции хочется прямо в описании класса написать?

10) Какой из стандартных контейнеров не может проверить индекс или ключ?
Для vector, deque есть метод at(), для set, multiset, map, multimap - find,
хотя в (multi)map и [] сработает отлично.

Вы когда-нибудь видели at() в программах? Я - нет. Всегда только []. А у него проверок нет! Для set и map [] _не_ сработает отлично - создаст новый элемент со значением по умолчанию. А это далеко не всегда то, чего хочется. Да, find есть, но опять же выдаст не ошибку, а итератор map.end().

11) "А ещё очень" хочелось бы "оторвать руки тому", кто бы сделал
std::vector<char>::size_type знаковым числом. Тогда на x86-32 сделать
массив байт больше 2Гб не получилось бы.

Правильно. Из-за горстки тех, у кого 4 Гб памяти и архитектура x86-32 должны страдать миллионы других программистов!

  • 15 лет назад, # ^ |
      Проголосовать: нравится +12 Проголосовать: не нравится
    1. В стандарте для каждого контейнера есть метод с проверкой.
    2. Пишите конкретно. Слова про perl и "свыше 1000 строк" - чистая вода.
    3. "std::vector не подходит по причине отсутствия проверок диапазонов" - уже писал. Подходит.
    4. "boost::array тоже" - см. boost::array::at()
    5. "В засорении динамической памяти в случае циклических ссылок" - не надо писать такой код. Если Вы не можете организовать объекты в иерархии времён жизни, то это значит, что Ваш код запутан и, скорее всего, будет подвержен и другим проблемам.
    6. "Нужно не забыть в каждом конструкторе!" - в каждом конструкторе нужно инициализировать все поля строго в порядке их объявления. Понмнить нужно только об этом.
    7. "А если тело функции хочется прямо в описании класса написать?". Изучать язык, на котором пишешь. Пытаться понять, какие плюсы и минусы были бы в воображаемых решениях.
    8. "Вы когда-нибудь видели at() в программах? Я - нет. Всегда только [].". Значит, все эти программы были написаны людьми, которые даже не знают, какие методы есть в стандартных классах. Либо им очень-очень была важна производительность.
    9. "Из-за горстки тех, у кого 4 Гб памяти и архитектура x86-32". Ну, виртуальной памяти почти у всех больше 2Гб. Так что большая горстка получается. А ещё надо учесть, что С++ используется и в связи, и в автоматизации оборудования, и ещё для многих применений, где могут быть и 16-ти и 8-ми разрядные процессоры. Что же, из-за горстки олимпиадных программистов должны страдать миллионы инженеров в промышленности? :-)


    Надеюсь, в этот раз получилось справиться с "местным форматированием".

  • 15 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится
    http://www.google.com/codesearch?hl=en&lr=&q=%22.at%28%22+lang%3Ac%2B%2B&sbtn=Search
15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится
Прочитал статью, она мне не очень понравилась. Все что пишет в ней Федор, конечно, безумно интересно, но как-то.. Как будто тут чего-то не хватает. Не смог я представить себе целостную картину)

Однако, ответы Федора на комменты, выложенные тобой, меня просто потрясли - уровень а**енности зашкаливает - нам всем нужно к этому стремиться. Респект Федору, однозначно.

плюспицот).

А вообще, когда выкладываешь что-то, можно воспользоваться средствами форматирования)) жирным текстом где-нибудь сделать или курсивом важные пункты) а у тебя все одна каша
15 лет назад, # |
  Проголосовать: нравится +12 Проголосовать: не нравится
Некоторые проблемы С++ будут решены в следующем стандарте - С++0х, который уже частично реализован в gcc 4.4 / 4.5
http://en.wikipedia.org/wiki/C%2B%2B0x
http://www2.research.att.com/~bs/C++0xFAQ.html
15 лет назад, # |
  Проголосовать: нравится +12 Проголосовать: не нравится
Позволю себе прокомментировать написанное в "статье". Сразу оговорюсь, что я не то чтобы хочу позащищать С++, но все же в посте выше, на мой взгляд, аргументация и некоторые факты не совсем корректны. Хоть в тексте и описывается, что речь идет о промышленном программировании, но все же заходит речь и об использовании языка в олимпиадах. Промышленного программирования я постараюсь не касаться, это слишком обширная тема, да и не нужно это тут. А вот по поводу С++ и олимпиад, я немного выскажусь. Итак...

Ошибка 1.1.1. Обращение к несуществующему элементу массива.
По какой-то причине автор одним из главных зол С++ выбрал отсутствие проверок в operator[] у массивов и стандартных контейнеров. Ну, с массивами допустим все в общем-то верно (хотя постоянное использование голых статических массивов вроде бы не сильно мешает многим победителям различных олимпиад), но претензии к вектору мне не совсем понятны.
Все известные мне современные реализации STL (SGI STL, Dinkum STL и STLPort) по умолчанию в дебаге имеют проверку на выход за пределы массива. Более того, версия Dinkum STL в составе Visual Studio по умолчанию имеет эту проверку даже в релизе. Что, кстати, стало причиной кучи holy wars "arrays vs vectors", "доказывающих" на тестах, что простой массив существенно быстрее даже со всеми включенными оптимизациями. 

Ошибка 1.1.2. Обращение к уже несуществующему объекту через указатель.
Не знаю, зачем нужно явное выделение памяти с помощью new в олимпиадных задачах (мы ведь сейчас об этом, да?). Мне вроде бы в последние несколько лет не пригождалось.

Ошибка 1.2. Использование неинициализированных переменных.
Оно то, конечно может и да, но давайте на практике попробуем не инициализировать переменную, например в VC++ 2005. Итак пишем код:
int i;
int j = i+1; 
Компилируем, видим: warning C4700: uninitialized local variable 'i' used. Предположим, что мы не смотрим на ворнинги (запомните это предположение). Запускаем в дебаге.. ой, что это: Run-Time Check Failure #3 - The variable 'i' is being used without being defined. 

Ошибка 1.4. Неожиданные для программиста свойства языка.
С этим я в общем-то согласен. Если недостаточно хорошо знать С++, можно иногда нарваться на неприятности даже в олимпиадах и это, наверное, основная проблема.
 
Возможность 2.2. Библиотеки шаблонов структур данных.
Ну, про проверку на выход за пределы мы уже поговорили. Теперь про 
for (std::vector<int>::size_type i = 0; i < a.size(); i++)
Вообще говоря, распространенной практикой в промышленном кодировании является такая форма записи:
for (size_t i = 0; i < a.size(); ++i)
Это не полностью корректно по стандарту, так как нет гарантии, что std::vector<T>::size_type - это size_t, но на практике вполне соответствует реализациям STL. В олимпиадах я лично вообще использую просто
for (int i = 0; i < a.size(); ++i)
Автору такая форма не нравится по причине ворнинга (помните предположение?). Но во время олимпиад, можно и пережить, мне кажется, пару лишних ворнингов.

Пункты "Ошибка 1.1.3. Удаление объекта изнутри его самогО" и "Возможность 2.1. Циклический импорт." вообще обычно говорят об ошибках проектирования, но я обещал о промышленном программировании не говорить...

Спасибо за внимание.
  • 15 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится
    как минимум, название топика  - Java vs C++ для промышленного программирования
    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      Ну, я ведь не только название читал. Во многих пунктах есть сноска про олимпиады. Да и рассматриваемые примеры куда больше относятся к сравнению языков для олимпиад, чем к сравнению их для применения в реальных проектах. Удобство написания кода на языке и предрасположенность к совершению ошибок - это лишь малая часть того, что под с таким названием нужно рассматривать. Да и даже в этих двух критериях описываются местами слишком конкретные вещи.
15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится
Дайте совет, что лучше выбрать для написания программ( для ACM ) на Java, под висту?
  • 15 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    Если хочешь использовать современные редактор кода с подсветкой, динамическим хелпом и т.п. - могу предложить использовать Eclipse . Версии Classic 3.5.1 (162 MB) вполне должно хватить. Более того, используя плагины можно расширить его функциональность. К примеру я сейчас под ним же пишу Java Servlet и управляю деятельностью сервера Tomcat. Нашумевший NetBeans не стал бы рекомендовать, ибо это куда более "тяжелый монстр" да и зачем "использовать экскаватор, чтобы вырыть ямку для саженца" :)

    Ну если ты не хочешь замарачиваться на какие то IDE - Блокнот тебе в руки. Многим этого хватает :)

    Ну да. Незабудь поставить себе JRE и JDK последних версий :)


    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      а IDEA теперь бесплатная вроде?
    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      Многим хватает блокнота для разработки на яве ? Я сомневаюсь в наличии хотя бы одного человека
    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      Насчет блокнота ты чушь спорол, признайся. Это если hello world в блокноте писать можно.

      FAR с колорером и блокнот - слегка разные вещи, помни об этом. И действительно, хочу посмотреть на человеков, что пишут в блокноте :)))
15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится
Это маньяки.
  • 15 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится
    Само собой мои знакомые не пишут промышленный код в блокноте, но для олимпиадных задач они его используют.Ну если серьезно - что такое есть в средах разработки, что не мог бы сам кодер - профессионал сделать без лишней помощи?
    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      В современных средах разработки есть множество подсказок и автодополнений кода, которые становятся особенно необходимыми, когда мы говорим о Java. Этот язык изобилует длинными идентификаторами стандартных функций и классов и громоздкими выражениями. При написании кода в Idea у хорошего программиста каждое, скажем, десятое нажатие на клавиатуру - это какой-нибудь Ctrl-Space или что-нибудь в этом роде. А если говорить об олимпиадном программировании, то тот, кто будет писать на Java в блокноте, может, конечно, гордиться своей суровостью, но контест он никогда не выиграет, потому что тупо слишком долго будет набирать код. А когда он насажает багов, как он будет отлаживать программу без среды разработки? Понапишет кучу отладочного вывода и будет изучать этот лог?
      • 15 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится
        Я (не знаю как Вы) веду речь о настоящих профи своего дела. Им не нужны никакие подсказки. Так же эти люди знаю язык, на котором пишут и они всегда знают, как и что будет работать , а при наличии хорошей соображалки программу и отлаживать не надо.
        • 15 лет назад, # ^ |
            Проголосовать: нравится 0 Проголосовать: не нравится
          Как хорошо, что эти люди не занялись в свое время олимпиадным программированием. С ними не было бы никакой возможности конкурировать.
          • 15 лет назад, # ^ |
              Проголосовать: нравится 0 Проголосовать: не нравится
            Ещё как занимались. Один из них - участник финала :)
            • 15 лет назад, # ^ |
                Проголосовать: нравится 0 Проголосовать: не нравится
              Удивительно, что не чемпион мира. Видимо, остальные члены команды оказались все-таки простыми смертными, а не богами.
      • 15 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится
        Я всеми руками ЗА IDE, но просто есть те, кто и без них не плохо обходятся. Не надо всех по себе ровнять.
        • 15 лет назад, # ^ |
            Проголосовать: нравится 0 Проголосовать: не нравится
          Я ни в коем случае не хочу обидеть ваших знакомых чудесных программистов или усомниться в их профессионализме. Левша блоху подковал безо всяких специальных инструментов. Просто их становление как профессиональных программистов наверняка произошло в то время, когда IDE были не так развиты, иначе они бы по-достоинству оценили их преимущества. А постоянно переучиваться очень сложно, особенно если ты привык к каким-то определенным инструментам разработки.
      • 15 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится
        А также интеграция с системами контроля версий, управления/сборки проекта (Maven, Ant), различными серверами приложений, различными фреймворками и т. д. и т. п. Без всего этого разработка большого промышленного приложения превращается в ад. Если делать это все без ide, скорость разработки будет меньше в десятки раз.
      • 15 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится
        Я пишу все SRM'ы прямо в арене (с KawigiEdit'ом), там нет автодополнений. И отлаживаю debug-output'ом :)
        • 15 лет назад, # ^ |
            Проголосовать: нравится 0 Проголосовать: не нравится

          +1. Именно про таких "крутых кодеров" я и говорил, которым не нужны всякие рюшечки IDE.

          А "блокнот" - так это метафора (забыл в кавычки выделить).

          Теперь я знаю 3-их хардкорных кодеров :)

          • 15 лет назад, # ^ |
              Проголосовать: нравится 0 Проголосовать: не нравится
            Если бы я был участником TopCoder, постоянно претендующим на выход в их онсайты (как Владислав), я бы тоже использовал исключительно саму арену, стараясь минимизировать число плагинов, потому что, насколько мне известно, там никакую IDE не предоставляют. Поэтому человек, привыкший к множеству плагинов и IDE на SRM-ах там просто не потянет.
        • 15 лет назад, # ^ |
            Проголосовать: нравится 0 Проголосовать: не нравится
          Ну а на финале в Стокгольме ты в чем писал? В vim? В kate? Или все-таки в eclipse?
          • 15 лет назад, # ^ |
              Проголосовать: нравится 0 Проголосовать: не нравится
            На финале естественно в eclipse) Там время не настолько критично как в topcoder'е. По работе я пишу в IDEA, а для себя - в emacs
    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      По моему даже олимпиадные задачи _очень_ неудобно писать в блокноте. Как они делают отступы в программах?

      Я сам зачастую пишу в FAR'e код, особенно олимпиадный. Но он на С++. Писать на Java даже в настроенном FAR'е у меня нет никакого желания.
      • 15 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится
        А в чем разница написания в фаре на яве и си++?
        • 15 лет назад, # ^ |
            Проголосовать: нравится 0 Проголосовать: не нравится
          В среднем на Java у меня получается код раза в два больший за счет более многословного синтакса (для олимпиадных задач). Некоторые вещи мне лениво набирать руками. Например, "throws IOException". В силу внутренней привычке на Java я использую гораздо более выразительные имена переменных, методов и классов. Многие имена имеют одинаковый префикс, так что AutoCompletor плохо разбирается в них. С другой стороны я знаю, что стоит мне открыть волшебную среду и я получу такое количество волшебных функций.

          В С++ синтакс покороче. Идентификаторы я использую поскромнее. Среда не дает мне настолько многого. У меня нет привычки писать в среде, так как я не писал на С++ в средах столько кода как на Java.
15 лет назад, # |
  Проголосовать: нравится +12 Проголосовать: не нравится
Только сейчас прочитал саму статью и увидел, что там есть фактическая ошибка - команда СГУ, ставшая чемпионом мира в 2006 году, писала на Java.
  • 15 лет назад, # ^ |
      Проголосовать: нравится -12 Проголосовать: не нравится
    Статья весьма старая. Команда СГУ писала на Java действительно только 1 год? Мнение о командах складывается о большинстве известных о ней фактов. А если они всего один раз изменили своей традиции - это ни на что серьезно наверно не повлияло. Я обновлю информацию из статьи, если в чем то автор серьезно заблуждается. Не думаю, что по мелочи есть повод менять авторский материал. 
    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      Я не призываю срочно менять авторский материал. Никакой традиции у нас нет, каждая команда сама на каком-то этапе выбирает себе язык программирования. Команда Saratov SU 3 (Мирзаянов, Эльтерман, Лазарев) писала на Pascal, потому как завоевывала медали в финалах еще в 2002 и 2003 годах. Другая команда Saratov SU 3 (Гольдштейн, Назаров, Якунин (2005)\Климов(2007)) писала на C++. Чемпионы мира 2006 года команда Saratov SU 2 (Алексеенков, Кулькин, Романов) выбрала для себя Java. А мы - медалисты 2009 и 2010 годов - Saratov SU 1 (Бондаренко, Матов, Пак(2009)\Якунин(2010)), тоже писали на C++.
      • 15 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится
        Поправка: СУ3 (Гольдштейн, Назаров, Якунин) писали на Delphi
        • 15 лет назад, # ^ |
            Проголосовать: нравится 0 Проголосовать: не нравится
          Да, спасибо. А тот сезон 2004/2005 был последним, когда на финале был разрешен Паскаль?
    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      Как-то странно вы ответили.

      "чемпионы мира другого года команда Саратовского ГУ пишет на C++"

      Вам же указали на _фактическую_ ошибку. Т.е. автор указал неправильный факт. ИМХО, такое надо исправлять обязательно.
15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится
Я тут один что ли на Паскале фигачу ":D
15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится
Я не буду не с кем спорить :) Но да все языки со встроенными библиотеками это просто прелесть ^_^ Насколько всё становится легко и расширяемо.

Но старый добрый Паскаль никогда не подводит,так как ты пишешь всё сам :) Что иногда очень превышает по времени программы СТЛ :)

Генка стал чемпионом мира :) И он на паскале фигачил :D
15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится
Хм... Как я помню наши в Болгарию поехали :)
15 лет назад, # |
  Проголосовать: нравится -11 Проголосовать: не нравится
> StaticArray<int, 5> a;
А вектор-то чем не угодил? Перформанс? А если перформанс - краеугольный камень, то о каком сравнении с явой вообще идет речь? :о

> К сожалению, стандартные контейнеры C++ поступают в духе Си и не
обеспечивают никаких проверок диапазонов
В дебаге все проверки есть. В ретейле их и не должно быть, ибо перформанс.

В целом я думаю любая статья в этом духе будет нубской. Потому что заголовок нубский. Термин "Промышленное программирование" по-моему придумали олимпиадники, которые пытаются оправдать свое занятие. Только от этого занятие олимпиадными задачами не перестало быть никак не относящимся к этому "промышленному программированию" занятием :о) Вам никогда в жизни не пригодится знание как написать максимальный поток минимальной стоимости, потому что когда реально такая задача перед вами встанет, у вас не будет ресурсов на поток, вам нужно будеть писать эвристику. Олимпиадки - это хобби. Это забавно, на это можно потратить пять лет жизни в ВУЗе, потому что вы еще не зависимы и у вас есть это время, олимпиадки даже могут принести желанную регалию, которая потом в вашем резюме будет сверкать ярче солнца и гиганты индустрии будут звать вас (это же наша цель, верно? но медалей каждый год 12, а нас тысячи...)
Кстати, кто-то мне говорил, что все наши легендарные АСМ-дядьки, которые пошли потом в большое Г, не очень-то там и аутперформят.

Вернемся к статье. Если кто-то поработал годик на двух языках, он не стал экспертом в них :о) Я пять лет пишу на PHP, и только последний мой проект занимает 32 тысячи строк, но я нуб в ПХП. Количество строк и количество лет не всегда о чем-то говорит.
Большие программные комплексы все равно будут писаться на С++, потому что там важна скорость. И как бы не росла мощность компьютеров, написание их на Java не станет worth doing.
Вообще поразительно, что сравнивается C++ и Java, а не С++ и C#.  Что, реально сегодня в индустрии много пишут на Java? В моем Ижевске основные предложения о работе были на .NET (я выкидываю 1С из рассматриваемого списка :о)). Даже epam, который так славится тем, что "они работают на всем" (господи, они даже писали на J#) в Ижевске не имел позиций для тех, кто кодячит на Java.
И хваленая кроссплатформенность Явы работает очень подозрительно. Проект, написанный под Windows очень сильно не хотел отображать русский текст, будучи развернутым на FreeBSD. Все исходники при этом честно были сохранены в UTF-8. На сервере с рутовыми правами шаманство помогло этого избежать, на сервере без рутовых прав все было тщетно, никакие ключи компиляции не спасали. При этом полностью переписанная кодяка на C++ перенеслась с лету, пришлось только дважды написать весь код для соккетов и потоков - но в данном случае это было worth doing. Да и кому нужна сегодня эта кросс-платформенность :о) Бывает нужно либо чтобы работало под Windows, либо чтобы работало под *-nix. Приведите мне пример, когда ни жить ни быть надо чтобы работало и там и там.
А вообще, когда я после олимпиадок попал в необходимость работать на дядю, я быстро для себя понял, что знания языка не важно. Вы не умеете писать на C#? Вы научитесь делать это за месяц. То, чему вы не научитесь за месяц, никому нафиг не надо :о) А как минимум месяц на то, чтобы понять, как корпорация, в которую вы попали, работает, вам все равно будет нужен.
А если фирма работает на Java, то даже если у вас есть миллиард доводов, что С++ лучше, вам придется писать на Java - мало кто спросит какой язык вам удобнее :о)
  • 15 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится
    Здравое рассуждение! Немного пессимистичное, но ИМХО абсолютно верное.  Пессимистичное потому что "программистов тысячи а медалек 12",  это да, но считаю что в первую очередь нужно стараться ДЛЯ СЕБЯ чтоб мозги не деградировали чтобы развивались все время.  А потом уже на медальки работать, на тренера, на сокурсников, на репутацию узкого круга людей который будет меняться все время)))

    ИМХО может я и не прав думайте сами решайте сами(с) пишите.
  • 15 лет назад, # ^ |
      Проголосовать: нравится +1 Проголосовать: не нравится

    Во многом не согласен с автором.

    StaticArray у автора всплыл как реализация safe-массива. Вы пишите, что в дебаге все проверки есть. Это о какой-то конкретной версии C++ от Microsoft? Поверьте, не все пишут на Microsoft Visual Studio последних версий. Более того, кажется, это касается только вектора, в то время как статические массивы остались обделены вниманием такой строгой проверки. Кстати, что такое "ретейл" - розничная продажа?

    Я не думаю, что термин "Промышленное программирование" придумали олимпиадники. Google дает свыше 300 тысяч ссылок. Да и вроде бы понятно, что это русский перевод английского enterprise.

    "Вам никогда в жизни не пригодится знание как написать максимальный поток" - ну не надо так категорично высказываться. Задачи бывают разные. Теория потоков имеет большие приложения - погуглите и найдете примеры. Конечно, если под программированием понимать исключительно написание систем документооборота, электронных магазинов, то да, вы правы.

    По поводу "не очень-то там и аутперформят" (правда, я не понял где): у меня достаточно обратных примеров. Если и говорить, что олимпиады это хобби, то хобби очень полезное и нужное. Как минимум техника программирования и умение размышлять будут многократно востребованы. А если еще из командных олимпиад вы вынесите понимание что такое команда, и как ей управлять, чтобы она лучше работала, умение элементарно общаться с людьми и доходчиво объяснять свои мысли, то вам цены не будет.

    "Большие программные комплексы все равно будут писаться на С++", "Что, реально сегодня в индустрии много пишут на Java?" Ижевск не столица силиконовой долины. Посмотрите статистику, например, здесь или здесь.

    По поводу кроссплатформенности Java - может вы ее просто готовить не умеете? "Приведите мне пример, когда ни жить ни быть надо чтобы работало и там и там." Например, разработка любого standalone приложения (хороший пример - IDE, и на Java их очень даже пишут: Eclipse, Intellij IDEA).

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

    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      Было бы кстати клево, если бы можно было редактировать свой комментарий. Мысли не всегда с первого раза удается выразить верно :о)

      Почему я сказал именно про Ижевск при сравнении предложений на Java и C# (помимо очевидной причины - я больше ни о чем и не знаю) - потому что понятно, Ижевск - такой же город, как и большинство городов России, за исключением столиц и может еще пары особо крутых мегаполисов, и предложения работы в целом должны быть похожи. Я не спорю, что Java может быть популярна overall (я не берусь сейчас судить bias у приведенной статистики) - у меня нет никаких зацепок чтобы сложить свое мнение, я говорю, что в моей провинции предложений на .NET было больше, чем на Java, причем значительно больше. Отсюда я делаю предположение, что в большинстве провинциальных городов России это так. А так как многие после ВУЗа и АСМ останутся в родном городе, то для них скорее встанет вопрос о том, что сейчас в их родном городе нужнее.
      Но это не интересная тема - я абсолютно согласен, что использовать маленький город для выводов о целой стране не верно.

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

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

      Ну опять же, я смотрел с точки зрения человека, который только закончил ВУЗ и идет на работу. Основной опыт и придет как раз на работе - имхо. К тому времени как карьерная лестница доведет до руководства проектом опыта уже будет вполне достаточно.

  • 15 лет назад, # ^ |
      Проголосовать: нравится +13 Проголосовать: не нравится
    >Только от этого занятие олимпиадными задачами не перестало быть никак не относящимся к этому "промышленному программированию" занятием

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

    >олимпиадки даже могут принести желанную регалию, которая потом в вашем резюме будет сверкать ярче солнца и гиганты индустрии будут звать вас (это же наша цель, верно? но медалей каждый год 12, а нас тысячи...)

    Нет, неверно. Не у всех людей одинаковые цели. 

    >Большие программные комплексы все равно будут писаться на С++, потому что там важна скорость. И как бы не росла мощность компьютеров, написание их на Java не станет worth doing.

    Далекое от реальности мнение, если честно. Инструмент нужно выбирать, исходя из требований. А требования зачастую вообще экономические. 

    >Что, реально сегодня в индустрии много пишут на Java? В моем Ижевске основные предложения о работе были на .NET (я выкидываю 1С из рассматриваемого списка :о)). 

    Реально много, и то, что ты этого не знаешь, странно.

    >Да и кому нужна сегодня эта кросс-платформенность :о) Бывает нужно либо чтобы работало под Windows, либо чтобы работало под *-nix. Приведите мне пример, когда ни жить ни быть надо чтобы работало и там и там.

    Коммерческая выгода подойдет как причина? Всегда лучше, когда продукт работает под разными операционками, а не под одной.

    >А вообще, когда я после олимпиадок попал в необходимость работать на дядю, я быстро для себя понял, что знания языка не важно. Вы не умеете писать на C#? Вы научитесь делать это за месяц. То, чему вы не научитесь за месяц, никому нафиг не надо :о) 

    Это всего лишь твой личный опыт, похоже. От реалий он тоже далек, производительность программистов отличается иногда в десятки раз. И зачастую, то, чему нельзя научиться за месяц, как раз таки и надо.

    >А если фирма работает на Java, то даже если у вас есть миллиард доводов, что С++ лучше, вам придется писать на Java - мало кто спросит какой язык вам удобнее :о)

    А зачем мне идти на работу в компанию, которая меня не устраивает?
    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      Взаимоисключающие строки...

      А зачем мне идти на работу в компанию, которая меня не устраивает?

      Далекое от реальности мнение, если честно. Инструмент нужно выбирать, исходя из требований. А требования зачастую вообще экономические. 


      • 15 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится
        А можно пояснить, что взаимоисключаещего? Я тогда может пойму, где не прав, или разъясню, что имел ввиду.
  • 15 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится
    >> StaticArray<int, 5> a;

    >А вектор-то чем не угодил? Перформанс?

    Шаблонный тип вроде вышеприведенного несет информацию о типе -- часто это бывает полезно (позволяет отсеять некоторые ошибки при компиляции и/или перегрузить функцию для массивов разной длины). Ну и оверхэд по памяти нулевой (что актуально для мелких массивов).

    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      s/типе/размере/
    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      Я кстати нубский вопрос возможно задам, а что, реально можно не тип данных а число в шаблоне указывать? :о

      • 15 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится
        Да, есть Nontype template parameters и template template parameters. Когда-то я писал несколько заметок по с++ на бывшем форуме нашего общежития, там есть одна про типы параметры шаблонов. Если интересно, то вот: http://faminet.bn.by/forum/show.php?T_ID=1913  
        • 15 лет назад, # ^ |
            Проголосовать: нравится 0 Проголосовать: не нравится
          В документе по ссылке ошибка; параметр шаблона не может быть значением вещественного типа.
          • 15 лет назад, # ^ |
              Проголосовать: нравится 0 Проголосовать: не нравится
            Там где less_than, ага. Сам же ниже потом и написал, что не может :) Давно это уже было..
      • 15 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится

        Да. Можно даже подсчитать факториал в compile-time. Сделать таблицу этих факториалов (пока, по крайней мере) нельзя.

        http://en.wikipedia.org/wiki/Template_metaprogramming

        • 13 лет назад, # ^ |
            Проголосовать: нравится -24 Проголосовать: не нравится

          Статью писал немного ламер.

          Во-первых С++ и Java по производительности немного, эээ, разного уровня языки.

          За переопределение new/delete конечно, руки надо оторвать и выбросить сразу. Если нет ума написать свой макрос и ПОЛЬЗОВАТЬ только его, в С++ делать нечего. Захотим мы подключить стороннюю либу, где такой же семипядный программер уже переопределил эти операторы под свой аллокатор - все пиши пропало, херачь проект заново.

          про int'овый size() - я чуть не описалсо... Для STL контейнеров есть BOOST_FOREACH, для массива прокатит проверка в духе:

          const size_t length = (длина массива);

          for( size_t index = 0; index != length; ++index);

          Если написано < или постфиксный оператор - программера надо гнать за парту.


          Сам я кстати нигде не учился (не смог попасть на бюджетные места в 99 - все уже купили до нас) - но прочел книжек 30 по С++ (Мейерс - редкое УГ, Саттер/Вандервурд рулит) в итоге рабатываю строителем, и пишу программы походу качеством повыше чем Вы. С уважением, пряморукий строитель.

          • 13 лет назад, # ^ |
            Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

            Конечно, все самые лучше программисты это те что без образования и как прилагательное, они сидят в деревнях и работают строителями (чего? Строитель орбитальных станций?)!=) 
          • 13 лет назад, # ^ |
              Проголосовать: нравится +1 Проголосовать: не нравится
            Согласен, что статья УГ, но можно спросить, как вы нашли этот топик, которому уже год?
          • 13 лет назад, # ^ |
              Проголосовать: нравится +3 Проголосовать: не нравится
            А не могли бы Вы (или кто-то другой) пояснить, почему, если я пишу
            for (int i = 0; i < n; i++)
            то меня "надо гнать за парту"?
            • 13 лет назад, # ^ |
                Проголосовать: нравится 0 Проголосовать: не нравится
              В данном случае для того, чтобы троллинг казался краше. Вообще, ++i не создаёт лишних (временных) переменных, которые нужны для i++, но в циклах и других подобных случаях, по идее, компилятор до этого сам догадается.
              • 13 лет назад, # ^ |
                Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

                =================================
                Не поленился, посмотрел ассемблерный код после C++ Builder.
                Что
                for (int i = 0; i < n; i++)
                что

                for (int i = 0; i != n; ++i)
                инкремент и проверка условия делается за 3 маш.команды.
                И в чем-то более сложном, типа
                a[++j + k + 1] = 10;
                a[j++ + k + 2] = 10;
                одинаково по 4 маш.команды.
                Может для другого компилятора или для более сложных выражений это не так, но я сложных выражений с оператором ++ и не пишу, чтобы на какие-то побочные эффекты не нарваться.
                Так что "гнать за парту" пусть останется на совести автора.
                 
                • 13 лет назад, # ^ |
                    Проголосовать: нравится +1 Проголосовать: не нравится
                  i++ и ++i не будут различаться в генерируемом коде до тех пор, пока переменная скалярного типа. Разница начинается, когда это какой-нибудь объект: в случае i++ будет вызываться копирующий конструктор. Но это уже триста лет как неактуально для цикла for, потому что оптимизатор все равно заметит, что этой копией никто не пытается воспользоваться.

                  А вот замена < на != реально маразм какой-то. Мало того, что просто вместо одной инструкции перехода будет другая, так еще и второй вариант опасен, если счетчик цикла идет не по простому инкременту.
                  • 13 лет назад, # ^ |
                      Проголосовать: нравится 0 Проголосовать: не нравится
                    Ну и куда уж нам до маразматиков из boost с их маразматическим BOOST_*_FOREACH, где в случае инкремента/декремента всегда используют != по вышеприведенной причине...
                    • 13 лет назад, # ^ |
                        Проголосовать: нравится +3 Проголосовать: не нравится
                      Вы меня запутали своими выше-ниже. Если есть реальная причина использовать !=, то естественно его нужно использовать. (Например, итератор std::set тупо не работает с <.) Я же объяснил, почему в вашем примере таких причин не было.

                      И вообще, этот сайт посвящен спортивному программированию, которое, несмотря на свое название, является соревнованием по решению математических задач в области теории вычислимости. То, что мы при этом пишем программы на языках, которые вообще-то не предназначены для наших соревнований, — всего лишь издержки формата соревнований.
          • 13 лет назад, # ^ |
              Проголосовать: нравится +11 Проголосовать: не нравится
            "Сам я кстати нигде не учился (не смог попасть на бюджетные места в 99 - все уже купили до нас)"

            Замечательная фраза. То есть все, кто учатся, покупают?
            • 13 лет назад, # ^ |
                Проголосовать: нравится -26 Проголосовать: не нравится

              Розовые очки сними.

               

              • 13 лет назад, # ^ |
                  Проголосовать: нравится 0 Проголосовать: не нравится
                Саш, я лично ничего не покупал и покупать не собираюсь. И в моей группе никто ничего не покупал. Один раз пытались принести подарок преподу за зачет-препод их отбрил. Был на первом курсе, правда, один препод у нас, который продавал книжки, и, если покупаешь книжки, зачет ставился только с учетом посещаемости. Но и зачет для тех, кто не покупал книжки(в том числе и я) проходил таким образом: препод вышел на полчаса и после возвращения спрашивал исключительно по билету. Так что фактически ребята, которые купили книжки, просто купили книжки и ничего за это не получили.
                Мои одноклассники тоже ничего нигде не покупали. Все, за исключением, может, парочки человек, честно поступили в те ВУЗы на те факультеты, куда хотели. И в Физтех, и в МИФИ, и в СГУ-никто ничего не платил
            • 13 лет назад, # ^ |
                Проголосовать: нравится +1 Проголосовать: не нравится
              Нет. Без оплаты прошел победитель городской олимпиады по математике.

              А Вы со своим вопросом можете обратиться к Елене Новиковой, если она до сих пор преподает в УдГУ, как оно там было в то время на поступлениях ;).

              Мне лично она тогда задала больше десяти дополнительных вопросов вместо полагавшихся двух-трёх и нашла-таки пробел в моих школьных познаниях. Кто ж виноват, что разложение числа e в ряд Тейлора в школьную программу не входит до сих пор?
13 лет назад, # |
Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

Мне кажется автор сильно драматизирует ситуацию. Например на счёт беззнакового размера для векторов (на счёт остального не знаю я пока не всё прочитал). С одной стороны это очень логично, что размер массива должен быть беззнаковым (трудно представить себе vector размера -1), с другой не обязательно писать так:
for (std::vector<int>::size_type i = 0; i < a.size(); i++), можно так:
for (unsigned i = 0; i < a.size(); i++), либо так:
typedef unisgned int uint; // эту строчку нужно писать всего один раз
for (uint i = 0; i < a.size(); i++)
  • 13 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится
    Очень неприятный момент с беззнаковым размером, это ситуация когда надо перебрать, например, все числа кроме последнего. Тогда, казалось бы нормальный код вроде:

    vector<int> v;
    for (int i=0; i<v.size()-1; ++i) ...

    перестает работать на пустом векторе. А работа с размерами вектора около нуля во много раз более частая, чем с гигантским размером ради которого нужен беззнаковый тип.
  • 13 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    Все эти варианты развалятся на куски с вектором, размер которого превышает 5 миллиардов, на 64-ех битной машине.

    Случай крайний, но в общем случае в таком контексте пишется size_t, а не unsigned или int.

     

»
13 лет назад, # |
  Проголосовать: нравится -34 Проголосовать: не нравится

Звучала статья как с++ фигня, а гава паинька. Мне лично понравилась статья про фабрику фабрик(по поводу гавы, вчасности) на хабре. Спасибо автору за книгу Мейерса!

»
13 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Пахнет холиваром).