C vs C++ :)

Это я про то, что нужно использовать std::vector на цпп, а не писать свою бажную медленную реализацию на ц. Использовать виртуальные методы, а не свои бажные и медленные указатели на функции в структурах. Про C vs CPP вообщем :) Я просто часто подобное вижу, приходиться поддерживать такое вот г.

> приходиться поддерживать такое вот г.

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

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

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

string s = boost::lexical_cast<string>(123);

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

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

Из описания проблемы -> "первым в голову приходит С++"
его и необходимо использовать.

>Скажите, в общем случае для подобной задачи можно ли сказать, что >(очевидное по-моему) удобство С++ не окупает потери при числодроблении, >и лучше попытаться сделать всё на С?

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

>а у нас они будут довольно ресурсоёмкими

наиболее ресурсоёмкими рассчётами (во всем мире),
на настоящиий момент, являются обработка и симуляция данных
ускорителя LHC в CERN (пентабайты данных).
"Рабочим" языком является C++, рабочей "framework" - система ROOT
http://root.cern.ch (в разработке которой я участвую).

> Прототип модели бегает на данный момент на матлабе,
> но скорость удручает.

Советую перейти на ROOT, как замену MatLab

> string s = boost::lexical_cast<string>(123);

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

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

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

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

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

>как в c/c++ проверить открыт ли файл не пользуя fopen&? ААААААААААААААААААААААААААААА Черт меня побери!!!!!!!!!!

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

> Еще хороший вариант - старый добрый паскаль. Возможно delphi.

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

> Это есть даже в классическом труде Страуструпа. Причина в том, что без const& параметр копируется, соответственно, тратится время на лишние операции с памятью и вызов конструкторов/деструкторов.

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

>наиболее ресурсоёмкими рассчётами (во всем мире), на настоящиий момент, являются обработка и симуляция данных ускорителя LHC в CERN (пентабайты данных). "Рабочим" языком является C++, рабочей "framework" - система ROOT

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

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

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

Насчет GEANT4 могу еще добавить, что по существу это достаточно тупая программа, на которую можно составить техзадание, спроектировать ее и несколько десятков лет ей пользоваться не особо развивая ее. Так этот GEANT4 собственно и появился на свет. Поэтому мне, как конечному пользователю абсолютно наплевать, на чем он написан, единственное требование к таким системам --- это полноценная документация, а не краткое введение + набор примеров.

Продолжу :). СЕRN --- это организация с приличным бюджетом и большим количеством людей. Поэтому CERN может себе позволить довести до рабочего состояния даже полное дерьмо. Поэтому то, как делают в CERN --- это не всегда верх совершенства.

Для полноты картины могу предложить еще такой вариант. Написать всю бизнеc-логику на Java, а потом заюзать ее с помощью AnyLogic, которая тоже, кстати, написана на Java, но, правда, стоит хороших денег... ;)

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

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

>Мне вот интересно, а почему прототип бегает медленно. Может быть, даже переписав на 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 на константу, если соответствующий параметр функции -- константа.

Сейчас простая числодробильня типа а+b работает почти везде одинаково, что на C/C++, что на Java/.NET, что даже на JScript.NET. Вероятно, Mathlab не должен сильно отставать.

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

>Что касается кеша и оптимизации работы с матрицами, то неужели у вас все так серьезно?!

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

> Что касается кеша и оптимизации работы с матрицами, то неужели у вас все так серьезно?!

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

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

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

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

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

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

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

Линейная система с 1000 переменными - задача довольно необычная для обычного программирования (с моей точки зрения как прикладного математика) :)

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

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

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

> а лучше годов с 17 устроиться работать на какую-нибудь фирму

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

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

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

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

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

> Если в голове нужного базиса нет, чтобы дисциплины самостоятельно освоить, то code monkey на php очередная получится.

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

> Если в голове нужного базиса нет, чтобы дисциплины самостоятельно
> освоить, то code monkey на php очередная получится.

лично меня впечатляет, как преподают программирование буржуи.
Вот пример одного из курсов по графике:
http://cagd.cs.byu.edu/~557/
а ведь это только малая толика того, что должен изучить студент ...