C vs C++ :)

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

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

Одно преобразование числа в строку чего будет стоить. Можете продемонстрировать как оно выполняется в крестах?

Если не принимать во внимание случаи клинического идиотизма разработчиков (тут уж от конкретного языка ничего не зависит), то такую программу на голом Си раз в 5 больше времени писать и раз в 10 больше ошибок copy-paste. Более выразительный язык предоставляет более широкие уровени абстракций, позволяя сконцентрироваться на проблеме, а не на низкоуровневых реализациях. Если не перегибать палку и не пытаться на С++ реализовать особо сложные задачи, более подходящие для языков уровнем ещё выше, то вполне себе язык. КПД, конечно, низковат по современным меркам, но ничего особо страшного.

Красота! А нельзя от этого: "boost::lexical_cast<string>(" и ")" - как-нибудь абстрагироваться? Что бы сконцентрироваться на проблеме, а не на реализациях? Перегрузить там оператор присваивания строке для типа int, например?

Ну если вы хотите себе проблем, то С++ позволяет получить их просто неимоверное количество. lexical_cast с явным указанием типа приведения понятен даже вам, а вот практически каждый программист при просмотре текста программы, в которой будет string s = 123 (да ещё в завуалированном виде), как минимум притормозится на этой строчке. Будьте проще.

> Перегрузить там оператор присваивания строке для типа int, например?

Можно, в билдере, по-моему, так и сделано.

int fstat(int filedes, struct stat *buf);

Зачем эти посредственности, когда есть Ада?

А первопричина в том, что в C++ входные параметры в теле метода "для удобства" (исторически для нафиг никому не нужной за такую цену совместимости с C) можно изменять, поэтому и приходится копировать, даже если это "удобство" не используется. В Аде же не только копировать не надо, вообще не надо думать, по ссылке передавать или нет. Компилятор сам разберётся. Эта прозрачность особенно полезна при использовании настраиваемых пакетов.

Наиболее ресурсоемкие расчеты на LHC -- это монте-карло детекторов на GEANT4, рабочим фреймворком ROOТ является только для конечной стадии анализа данных и как средство для хранения классов C++ в файлах. Рабочим же фреймворком для эксперимента ATLAS. например, является Athena. И GEANT4 и Athena (под Athena я подразумеваю весь набор алгоритмов для реконструкции, симуляции и т.д.) обладают дерьмовой документацией и охрененным количеством классов. Так что предлагать их в качестве хорошего примера я бы не стал. А любителям покричать, что система классов С++ делает документацию не столь необходимой я предлагаю в качестве упражнения до конца разобраться в коде GEANT4.

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

C этим полностью согласен.

Если моя прежняя догадка верна о том, что эта задача из области agent-based modeling, то это будет неплохой вариант.

Мне вот интересно, а почему прототип бегает медленно. Может быть, даже переписав на C/C++, вы получите не намного более быстрый код? Я просто никогда не использовал Mathlab, хотя многие знакомые его нахваливали. Неужели его скрипты так сильно уступают в скорости самописному коду?! Одолевают меня смутные сомнения...

Дык дело не в скрипты vs самописный код, а в том, что числодробильня типа a+b всяко будет быстрее в компилируемом языке (если только интерпретатор не производит компиляцию запускаемого им кода и предполагается, что работает именно скриптовый код, а не библиотечный скомпилированный, как может быть в случае использования стандартных операций с матрицами, например), и во-вторых, в С/С++ коде больше простора для низкоуровневой оптимизации (не надо думать, что компилятор все сделает за вас, поскольку в момент компиляции, для примера, может быть недоступна информация о размере используемых матриц, а как раз от этого размера может зависеть оптимальный код). Для примера могу привести блочные алгоритмы с большими матрицами, которые могут быть на порядок(именно так, сам проверял) быстрее, чем наивный цикл, только потому что в компьютере есть такая штука как кэш.

> > Никто не будте писать

> Это свойство языка, компилятора и неких "всех", от имени которых вы высказались?

Т.е. вы таки пишете спагетти-код?

> > j = 3; k = i << j; и k = i << 3;

> С этим к производителю конкретного компилятора, при чем тут язык?

если функция имеет вид

inline unsigned char c_nth_byte(unsigned long long value, unsigned byteno) {
  assert(byteno <= sizeof(value));
  return value >> (byteno * CHAR_BIT);
}

то она всегда будет медленнее, чем

template<unsigned byteno> inline unsigned char cpp_nth_byte(unsigned long long value) {
      assert(byteno <= sizeof(value));
      return value >> (byteno * CHAR_BIT);
}

Да, я знаю, что они не эквивалентны.

Неправда. При inline-подстановке компилятор точно так же может заменить byteno на константу, если соответствующий параметр функции -- константа.

Что касается кеша и оптимизации работы с матрицами, то неужели у вас все так серьезно?! Думаю, что в этой теме большинство программистов не разбирается, и я в том числе, поскольку еще не сталкивался с такой острой необходимостью.

У меня да, но я не тот анонимус с матлабом :)

Perfomance drop при обработке больших матриц с помощью обычных, незаточенных алогоритмов просто дикий.

Это я понимаю. Вопрос в том, знают ли об этом биохимики? ;)

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

Идея примера взята из реализации radix sort одним коллегой. Там внешний цикл по byteno, и компилятор, естественно, его не разворачивает и 8 разных инлайнов не генерирует, если обычной фунцией пользоваться. А если заменить цикл на рекурсивный шаблонный вызов - то разворачивает и генерирует, и становится (вся реализация в целом) на 30% быстрее...

Я тут по телику не так давно одного перца видел, который советы давал о выборе будущей профессии. Так, он на полном серьезе заявил, что для того, чтобы стать "программистом", поступать в вуз не надо, а лучше годов с 17 устроиться работать на какую-нибудь фирму и дальше продолжать в таком же духе свою "карьеру". Еще этот перец обмолвился о ВМК МГУ, что мол тамошних дядек, студентов переростков, можно нагнать года за два... А ты говоришь LAPACK... :)

Инженер по специальности Котло- и Реакторостроение знает, отчего ж биохимику не знать? ;)

Конечно же, полная фигня. Математика хотя бы в том объёме, что дают на начальных курсах, крайне необходима. А систематизация и обработка данных, которую прививают на старших курсах инженерной специальности, вообще в принципе думать учит :) Если в голове нужного базиса нет, чтобы дисциплины самостоятельно освоить, то code monkey на php очередная получится.

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

А чо? Всё правильно: вызубрил несколько десятков паттернов - и вперёд. Что ещё надо программисту?

Я тоже так думаю, но нас становится все меньше и меньше... По крайней мере, я знаю немало [малообразованного] народа, которые разделяют точку зрения того перца из ящика. Селяви.