C vs C++ :)

У матлаба транслятор в сишный код, вроде, был. Не игрались с ним?

Я чего-то не понял, ну заводишь структуру, которая описывает эти объекты и набор функций для работы с ними. Если потом добавишь в структуру чего-то еще, то если в уже написанных функциях это "чего-то еще" не требуется, то они и остаются как есть. Все это легко реализуется на C. Если реализовать подобную схему на С++, то все будет отличатся только синтаксисом вызова функций (вместо f(a,x) будет a->f(x), ну и f будет в глобальной области видимости). Вообщем вывод таков, если тебя не раздражает громоздкость С++ -- пиши на нем. Меня раздражает, поэтому я бы выбрал С. На С вполне можно писать большие проекты, если руки из правильного места растут. А если нет -- то и на С++ получится дерьмо. В любом случае решать тебе.

mex-ы пытались делать, но такая фигня получалась... Не осилили. В принципе переписывать на что-то компилируемое рано или поздно всё равно придётся.

О, понабежали фанатики "голого си".
Числодробительство - оно во всех компилируемых языках одинаково. А дерьмо можно написать и на C и на C++ (только причины и виды дерьма будут различаться).

Фанат С/С++?

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

В общем, погугли на тему, зачем в стандарт C99 включили модификатор restrict.

С? С++? Нет. Забудьте про эти устаревшие, немощные и бесперспективные языки. PHP. Только PHP. Стабильно. Наджено. Глобально. Выбор достойный профессионалов.

С++ - это набор объектных прибамбасов над Си. Т.е. С++ программа, использующая эти прибамбасы по определению будет сложнее, чем программа, написанная на Си.

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

Объектно-ориентированный подход оправдан в случаях, когда имеется несколько разных объектов, обладающих общими свойствами. Например в учебниках любят приводить в пример геометрические фигуры изображаемые графически - треугольник там, круг, квадрат.. Все такие фигуры с точки зрения их отрисовки обладают общими свойствами (цвет, размер, положение на холсте) и методами (закрасить неким цветом, отобразить на мониторе или на принтере, масштабировать, и т.п.). Очевидно, что алгоритм (метод) закраски круга будет отличаться от алгоритма закраски треугольника, но все геометрические фигуры имеют общие свойства и методы и могут быть абстрагированы до некоего абстрактного класса "геометрическая фигура" от которого и будут наследоваться конкретные реализации конкретных геометрических фигур со своими собственными, уникальными реализациями общих для всех фигур методами - так, что программа более высокого уровня сможет, например, отображать фигуры не вдаваясь в детали их реализации - прямоугольник это или овал, она просто будет просить некий геометрический объект отрисовать себя в заданном месте, например. Это сильно упрощает жизнь в сложных системах, но если ваша задача не подразумевает использования подобных абстракций - вам не необходимо использовать объектные возможности С++.

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

> Только PHP

А вот этого придурка не слушайте. Ни один интерпретируемый язык или т.н. "безопасный" типа джава или net не подойдет для работы с матрицами, поскольку на каждое обращение к элементу массива они будут осуществлять проверки - не вылетели ли вы за пределы массива, например. Это сильно снижает производительность.

Зануда, человек жжот, а ты всё буквально принимаешь... =/

Если в С++ не использовать виртуальные функции и исключения, то производительность будет идеентична С.

>производительность будет идеентична С

Я теперь тоже так думаю. Может быть, это не совсем тру уэй, но мне классы в данном случае показались сподручнее чем структуры. На них и остановимся пока что :) А вырастем большими - перепишем всё на пых :)

На С++ тормоза написать куда проще чем на С, если использовать не совсем умеючи. Лично видел - после замены аргументов одной функции на оный с const &, программа стала работать раз в 10 быстрей. Ну а ежели умеючи - то С++ лучше.

> С другой стороны, как я уже говорил выше, всё, что вы напишете на Си, вы так же легко напишете и на С++, без разницы в производительности и даже без какой-либо принципиальной разницы в синтаксисе.

выше уже был упомянут restrict. В С++ его нет

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

Хм... а может Fortan? Он как раз под числодробление очень хорошо заточен.

Если голый Си ведет к траходрому, почему бы не писать на помеси?

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

Обработка исключений не работает?

> Черт меня побери!!!!!!!!!!

Кстати, да :-)

try... catch фто-ли? с ней не хочу ;-) Беэ можно?

А может, попробовать D?

В С++ есть STL и vector. А в C всё надо самому писать, в т.ч. и реализацию массива.

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

>>В С++ есть STL и vector. А в C всё надо самому писать, в т.ч. и реализацию массива.

Простите, конечно, но довольно объёмно, намекните конкретнее, насчёт Stl и vector'а.

> Ни один интерпретируемый язык или т.н. "безопасный" типа джава или net не подойдет для работы с матрицами, поскольку на каждое обращение к элементу массива они будут осуществлять проверки - не вылетели ли вы за пределы массива, например. Это сильно снижает производительность.

Тот товарищ, очевидно, шутил на счет пых-пых. Но ты не прав относительно java и .net. Во многих случаях они умеют обходится без таких проверок. Прогресс не стоит на месте.

А чем FORTRAN не устраивает? (если конечно не g77) Если много свободного времени, то можно посмотреть в сторону ADA имхо. Хотя специализированные средства смотрелись бы явно лучше.

Это агентная (agent-based) модель?

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

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

>Лично видел - после замены аргументов одной функции на оный с const &, программа стала работать раз в 10 быстрей.

Очень интересно. Не ткнёте во что-нибудь, где подобные вещи описываются? Или они зависят от многих факторов (могу предположить, что играют роль ОС, компилятор, объем памяти)?

> Они для системного программирования, у них много своих подводных камней. Еще хороший вариант - старый добрый паскаль.

Чииво?? Старый добрый Паскаль - яэык того же уровня, что и старый добрый це. Я уж не говорю о том, что, наверное, только вам одному известно, что отличает "системное программирования" от просто программирования :-)

>Даже не знаю, кто вам такую глупость посоветовал

Никто не советовал... Это исторический факт, у нас (в нашей группе) все критические в рассчётах вещи пишутся и писались на С. Русские биохимики выбирают С/С++ :) Да и не только у нас. В старину были конечно и мастодонты, использующие фортран. Но эта традиция умерла, к сожалению.

>старый добрый паскаль

WTF is паскаль?

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

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

Лично я чисто расчетную задачу писал бы на ограниченном диалекте плюсов - C-с-классами-и-шаблонами, без сложных иерархий наследования (особенно виртуального). И смотрел бы матбиблиотеки от производителей процесоров (Intel, AMD).

> Русские биохимики выбирают С/С++ :)

Если русские биохимики так круты, что могут писать на C, то что останется делать нам, программистам, лет через 10 или 20? Страшно подумать даже! :)

Кстати, если не будете много пользоваться ООП, то будет работать быстро даже на Java, но тут требуется глубокое понимание многих вещей и опыт.

> Как ни странно, C++ может быть быстрее C, если правильно писать - за счет шаблонов и генерации разного кода для разных параметров - на плюсах такое выражается более-менее понятным способом, а на C - либо копипаст, либо хакерство на макросах.

Это всё не имеет отношения к производительности результирующей программы.

>Простите, конечно, но довольно объёмно, намекните конкретнее, насчёт Stl и vector'а

В STL реализованы стандартные типы данных вроде вектора - контейнера для хранения однотипных объектов (читай массива объектов). Любой пользовательский тип данных, реализующий необходимые для данного контейнера операторы (в частности сравнения двух объектов данного типа) автоматически получает функциональность данного контейнера (добавление нового элемента, сортировка, поиск и пр.), при этом контейнер сам будет управлять выделением памяти, механизм которого при необходимости можно изменить. Все эти возможности, предоставляемые в C++ стандартной библиотекой, отсутствуют в С, в котором для любого нового типа данных необходимо с нуля реализовывать свои собственные алгоритмы. Приходится либо заново изобретать свой собственный велосипед на С, либо пользоваться сторонней библиотекой. Но зачем использовать чьи-то сторонние разработки, непонятно кем написанные, с неизвестными характеристиками и потенциальными ошибками/недочётами, когда есть С++. Фактически, вопрос выбора С или С++ стоит так: "Почему НЕ использовать С++?".

>в С, в котором для любого нового типа данных необходимо с нуля реализовывать свои собственные алгоритмы.

Нифига подобного. Стандартная библиотека С включает в себя функции высшего порядка qsort и bsearch :)

>Если в С++ не использовать виртуальные функции и исключения, то производительность будет идеентична С.

Неправда (по поводу виртуальных функций). Никто не мешает мне определить в структуре на С несколько указателей на функции. Я так иногда делаю. Механизм вызова их почти такой-же как вызов виртуальных функций С++. Если функция не является тривиальной (типа f(a,b){return a+b;}) или вызывается редко,то накладные расходы на вызов этой функции будут незначительны вне зависимости прямой это вызов или косвенный.

Да, да. Спасибо. Я C++ сейчас использую. Но я так и не понял как с помощью STL узнать открыт ли файл...

>Но я так и не понял как с помощью STL узнать открыт ли файл

А можно поподробнее зачем это нужно?

>Да, да. Спасибо. Я C++ сейчас использую. Но я так и не понял как с помощью STL узнать открыт ли файл...

LOL :) Анонимус, подписываться надо, например "тот самый анонимус с файлом". И вообще открой новую тему. При чём тут STL?

Хорошо. Я писал : Как в c/c++ узнать открыт ли файл. Так. И Ты(seiken) написал : ляляля в c++ есть STL и vector. Так.

Мне надо узнать открыт известный мне файл или нет. Не пользуя try, catch(не знаю как и не нравится) и fopen(т.к. если файл 'закрыт' -> он открывается).

Анонимус с файлом.

>> Лично видел - после замены аргументов одной функции на оный с const &, программа стала работать раз в 10 быстрей.

> Очень интересно. Не ткнёте во что-нибудь, где подобные вещи описываются? Или они зависят от многих факторов (могу предположить, что играют роль ОС, компилятор, объем памяти)?

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

>АААААААААААААААААААААААААААААА Черт меня побери!!!!!!!!!!

нет, биореактор эффективнее

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

fstream f;
f.open("somefile", ios::in);

if(!f)
{
 cout << "Damn! File not opened!" << endl;
}

Добрый день!

Если вы не программист, а биохимик, как вы сами говорите, то на вашем месте я бы обратил внимание на что-то более простое, чем C/C++ - в частности, на .Net. Минусы тут следующие:
1. Производительность все-таки ниже, чем у кода, написанного на C++ (за исключением случая, когда используется так называемый небезопасный (unsafe) код). В принципе, если использовать готовые библиотеки, то можно избежать сильного проигрыша в производительности.
2. Привязанность к одной платформе - Windows.
Плюс один, он же главный: простота разработки.

Если .Net вас не устраивает, то ориентируйтесь на C++. Да, язык более сложный, чем C, но и возможностей у него значительно больше и они очень пригодятся, когда придется добавлять все новые и новые функции в вашу программу.

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

Очень просто и очевидно. Надо сгенерировать PHP-страничку, которая проверяет наличие файла (насколько я помню, в PHP есть специальная функция, в Perl'е точно есть, `-e' называется), скормить её интерпретатору и распарсить вывод.

> fopen(т.к. если файл 'закрыт' -> он открывается)

Угадай, что будет, если он уже открыт.

>>> Лично видел - после замены аргументов одной функции на оный с const &, программа стала работать раз в 10 быстрей.

>> Очень интересно. Не ткнёте во что-нибудь, где подобные вещи описываются? Или они зависят от многих факторов (могу предположить, что играют роль ОС, компилятор, объем памяти)?

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

ссылка - это указатель семантически, то есть при передаяе константной ссылки, был передан указаль на объект, а не запихнут этот объект в стек (а потом оттуда удален)

Ну будет ошибка.

> Очень просто и очевидно. Надо сгенерировать PHP-страничку, которая проверяет наличие файла (насколько я помню, в PHP есть специальная функция, в Perl'е точно есть, `-e' называется), скормить её интерпретатору и распарсить вывод.

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

А generator'y'glukoff если это работает спасибо.

С чего бы это?