C vs C++ :)

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

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

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

Hint:

$cat fopen.c

#include<stdio.h>

int main()

{

FILE* ff = fopen("aa","r");

FILE* gg = fopen("aa","r");

printf("ff:%.16X\n",ff);

printf("gg:%.16X\n",gg);

return 0;

}

$touch aa

$make fopen

$./fopen

ff:0000000000501010

gg:0000000000501250

Я не телепат, но по-моему, то что тебе надо -- это рекомендательная или обязательная блокировка файла (man lockf)

А что fopen в таком случае вернёт?

Прекрасно, и что мне с этими 50505001 делать? Именно блокировка и нужна.

В случае обязательной блокировки она вернет 0, если блокировка была получена ранее кем-то (в том числе другим процессом). Прочитай man страницу и все станет ясно. И еще /usr/src/linux/Documentation/mandatory.txt и /usr/src/linux/Documentation/locks.txt.

>Прекрасно, и что мне с этими 50505001 делать? Именно блокировка и нужна.

Я этот исходник привел к тому, что fopen для подобных целей бесполезен.

>Но мы не знаем, нужна ли вообще сортировка автору

Причём тут именно сортировка. Этот же механизм позволяет реализовать другие алгоритмы и/или структуры данных (см, например, glib).

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

Ясно, спасибо за помощь

>Причём тут именно сортировка. Этот же механизм позволяет реализовать другие алгоритмы и/или структуры данных (см, например, glib).

Позволяет реализовать и располагает стандартной библиотекой - это немного разные вещи.

>С++ просто более высокоуровневый и более гибкий язык по сравнению с С

Гибкий и высокоуровневый --- это лисп (CL и Scheme). А С++ -- это набор костылей к С, который создает иллюзию гибкости и высокоуровневости. Если мне нужна гибкость, которую трудно реализовать на С и в то же время эффективность, я воспользуюсь Scheme+C . Либо R+C для некоторого класса задач обработки данных.

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

Попробуй повторно открыть файл из заблокировавшего его процесса, т.е. тот же пример, но с блокировкою - вернет ли оно NULL? :-)

> Позволяет реализовать и располагает стандартной библиотекой - это немного разные вещи.

Точно!

"Позволяет реализовать" == "гибкий" "располагает библиотекой" == "развитый" "располагает замуженной медленной библиотекой в которой намешана куча самых разных вещей, не имеющих между собой ничего общего" == "мощный"

>> Попробуй повторно открыть файл из заблокировавшего его процесса, т.е. тот же пример, но с блокировкою - вернет ли оно NULL? :-)

Приложение под винду.

Ну не тыкайте вы хоть в этой теме своим замечательным лиспом в наши грубые сишные быдломорды :-)

> Попробуй повторно открыть файл из заблокировавшего его процесса, т.е. тот же пример, но с блокировкою - вернет ли оно NULL? :-)

Да, тут я стормозил :). Могу предложить для получения блокировки создавать файл /tmp/foo при помощи open с флагами O_EXCL|O_CREAT. И удалять его при снятии блокировки. Это гарантирует, что нормальный дескриптор ( >=0 ) open вернет только в том случае, если файла /tmp/foo еще не существует. Это также работает в случае нескольких процессов (т.е. race conditions не будет).

> Приложение под винду.

Ну тогда надо идти и читать документацию на работу с файлами в винде. Ни в стандарте на C, ни в стандарте на C++ таких вещей (блокировок) вроде бы нет.

Хотя, если программа однопроцессная (и однотредовая), то можно просто создавать дополнительный файл при помощи fopen и потом проверять его существование при помощи того же fopen.

> Приложение под винду.

Ну и что?

Что-то мне подсказывает, что на освоение Scheme+C уйдёт больше времени, чем на освоение С++. Здесь подчеркну: освоение до приемлемого уровня для данной конкретной задачи. И полученные преимущества при использовании Scheme+C не окупят затраченного на него времени. Здесь ещё немаловажно учесть особенности конкретной разработки, а именно наличие программистов, владеющих Scheme+C для дальнейшего развития системы. Но поскольку нам всё это не известно, приходтся ориентироваться на усреднённые характеристики языков. И С++ в данном случае выигрывает у Scheme+C. Банально программу, написанную на одном языке проще развивать, чем написанную на нескольких, при прочих равных условиях. IMHO, разумеется.

> Гибкий и высокоуровневый --- это лисп (CL и Scheme). А С++ -- это набор костылей к С, который создает иллюзию гибкости и высокоуровневости. Если мне нужна гибкость, которую трудно реализовать на С и в то же время эффективность, я воспользуюсь Scheme+C . Либо R+C для некоторого класса задач обработки данных.

А можеш показать пример как достигается гибкость связыванием Scheme+C, R+C?

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

> Неправда (по поводу виртуальных функций). Никто не мешает мне определить в структуре на С несколько указателей на функции. Я так иногда делаю. Механизм вызова их почти такой-же как вызов виртуальных функций С++.

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

> Если функция не является тривиальной (типа f(a,b){return a+b;}) или вызывается редко,то накладные расходы на вызов этой функции будут незначительны вне зависимости прямой это вызов или косвенный.

С этим никто не спорит. :)

Схема в разы проще С, и на два порядка проще С++.

Гибкость достигается не связыванием схемы с С, а при помощи собственно схемы. C необходим в тех частях программы, где есть проблемы с производительностью. Сходи на www.r-project.org например (это по поводу R+C). Там (а точнее в CRAN) есть полно модулей такого типа (которые внутри себя имеют части, написанные на C). Ну а насчет того, какую гибкость дает схема,R и прочие языки где функции являются first class entities --- это нормальные функции высшего порядка для начала. Кроме того автоматическое управление памятью тоже является плюсом. Напомню, что речь идет о софте предназначенном для применения в исследовательской работе. Основная особенность такого софта --- невозможно заранее написать ТЗ, даже если и напишешь,то когда программа будет готова оно уже поменяется, причем не чуть-чуть (что C++ легко переваривает), а довольно сильно. А C++ как раз и требует это ТЗ для построения иерархии классов. А если иерархия не соответствует действительности --- то программирование на C++ превращается в ад. Все написанное выше мое личное мнение, разумеется.

> mex-ы пытались делать, но такая фигня получалась...

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

Вообще, раз так с матлабом всё чудестно складывается, то я бы и не отрывался от него (его библиотек)

> С++ - это набор объектных прибамбасов над Си.

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

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

Давайте ещё и компилятор сами напишем. Тьма библиотек, в том числе и расчётных, куда делись?

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

Надо заметить, что на заре вычислительных машин не было программистов. Были учёные (физики, химики, геодезисты, ...), которые все концептуальные вещи и создали. Это только потом понабежали code monkeys, которые расчёт ядерного взрыва тумблерами в 4кб памяти написать не в состоянии ;)

> Очень интересно. Не ткнёте во что-нибудь, где подобные вещи описываются?

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

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

Даёшь lisp/scheme + сишные математические библиотеки через ffi. Быстро новые фичи добавлять (на лиспе это в сто раз проще, быстрее и мощнее, чем на плюсах), быстро работает (считать будет всё равно библиотечный код).

> Если мне нужна гибкость, которую трудно реализовать на С и в то же время эффективность, я воспользуюсь Scheme+C .

+1

> Что-то мне подсказывает, что на освоение Scheme+C уйдёт больше времени, чем на освоение С++. Здесь подчеркну: освоение до приемлемого уровня для данной конкретной задачи.

Вы шутите? Для того, чтобы начать _нормально_ писать на схеме (не на коммон лиспе... хотя, в принципе, один фиг), нужно освоить первые несколько глав из одной книжки (SICP). Язык очень лёгкий в усвоении, уже через день, переключившись на C/C++, будете писать (if x ... вместо if (x).

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

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

Мне кажется, что это не зависит от языка. :) Кстати вопрос, сколько проектов, размером с те, о которых вы писали, было реализовано вами на Scheme+C?

>Напомню, что речь идет о софте предназначенном для применения в исследовательской работе. Основная особенность такого софта --- невозможно заранее написать ТЗ, даже если и напишешь,то когда программа будет готова оно уже поменяется, причем не чуть-чуть (что C++ легко переваривает), а довольно сильно.

Знаем, видели. Сложности разработки особенно заметны, когда исследовательская работа в данной области идёт параллельно с непосредственной разработкой программы. Проблемы, возникающие в таких проектах при использовании С++ в принципе решаемы, но, к сожалению, у меня нет опыта разработки программ такого уровня на Scheme+anything, поэтому утверждать, что однозначно С++ лучше Scheme+C в данном случае не буду :) Всё зависит от конкретной задачи и разработчика(-ов).

>Вы шутите? Для того, чтобы начать _нормально_ писать на схеме (не на коммон лиспе... хотя, в принципе, один фиг), нужно освоить первые несколько глав из одной книжки (SICP). Язык очень лёгкий в усвоении, уже через день, переключившись на C/C++, будете писать (if x ... вместо if (x).

SICP читал, но примеры там приведены детские (что и понятно, эта книга - введение в программирование для начинающих). Одно дело писать программы уровня лабораторных работ по предмету "программирование на ЯВУ", и совсем другое - использовать максимально эффективно язык в реальном проекте. Для этого нужен опыт разработки на Lisp/Scheme. И это в добавок к тому, что вы уже должны хорошо знать С для переписывания узких мест программы.

> Мне кажется, что это не зависит от языка. :)

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

> Кстати вопрос, сколько проектов, размером с те, о которых вы писали, было реализовано вами на Scheme+C?

Как водится, ни одного :) Более того, т.к. проекты всё больше привязаны к железу, то напрягаться с сопряжением не слишком распространённых сишных библиотек и сисколлами пришлось бы изрядно. Что не мешает удивляться лаконичности Scheme и его широким возможностям при малом объёме кода.

Кстати говоря, в случае с C++ пришлось писать вагон обёрток, тут практически паритет получается.

> и совсем другое - использовать максимально эффективно язык в реальном проекте. Для этого нужен опыт разработки на Lisp/Scheme. И это в добавок к тому, что вы уже должны хорошо знать С для переписывания узких мест программы.

Кажется, донести идею у меня не получилось... Я не крашу вещи в чёрно-белые цвета, у всего есть своя ниша, но вот готового к употреблению в среднестатическом проекте специалиста по scheme получить (обучить) проще, чем по плюсам, т.к. для усвоения scheme + sos (lisp + clos) более простой и единообразный, чем плюсы. На плюсах писать плохо и безобразно легче, чем на диалектах лиспа, и фактор опыта в этом случае играет большую роль. Сами подумайте, какая польза будет от новичка в C++ для проекта сложностью выше среднего. Речь вообще будет идти о возможности его примениния :)

В рамках исследования, пока ищется модель, вполне обосновано использовать только Scheme. И, соответственно, можно всё довольно безболезненно и быстро менять. Anything добавляется в последнюю очередь, на стадии оптимизации :)

Пишите на Java, и не естествуйте себе мозги. Они вам еще пригодятся.

>Пишите на Java

Почему на Java-то? :)

> Почему на Java-то

Что бы массивы медленнее обсчитывались.

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

Неправда. Например, сановский JIT (по крайней мере в server mode) убирает эти проверки, если может перед компиляцией верифицировать, что индекс всегда в нужном диапазоне. В описанной задаче именно так и будет.

> Это сильно снижает производительность.

Не верю. Если помимо просто доступа к массиву делается еще что-то полусущественное, то практически не будет заметно.

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

На этом месте принято просить убиться об стену. GSL ему в помощь.

> В описанной задаче именно так и будет.

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

>На этом месте принято просить убиться об стену. GSL ему в помощь.

GSL это GNU Scientific Library ? Во первых оно GPL со всеми вытекающими, во вторых vector там определен только для простых типов.

скорость обсчета массивов на java сравнима с сишной

> сравнима

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

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

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

Имеет, имеет. Никто не будте писать руками инлайновых 8 функций типа "1-й байт лонг лонга", "2-й байт", и т.д. А на C++ они генерируются в одну строку. Разница же в производительности между

int i, j, k;

j = 3;

k = i << j;

и

k = i << 3;

как ни странно, значительна (по крайней мере, на x86).

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

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

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

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

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

И чего они сортируют? Указатели на void, вызываю внешнюю не инлайновую функцию сравнения через указатель?

По поводу массивов -- видел один прожект, напмсанный на C (для максимальной скорости, естественно), со своими реализациями array, string, map (как водится в прожектах на C). Реализация array, например, хранит те самые void* и работает раза в 3 медленнее.

То же касается и "структур с указателями на функции" -- зачем каждый раз писать то, что в cpp есть на уровне языка?? Для производительности?

@#$%^ ...

Не понял, к чему этот монолог. Сам с собой споришь?