Здравствуйте, Erop, Вы писали:
P>>а на счёт скорости разработки — сколько времени этот средний программист C убьёт на отладку? E>Не факт, что больше, чем С++... E>У С-шника будет больше строчек, зато ошибки все будут простые, а у С++ника строчек булет меньше, зато ошибки будут заковыристее...
у C-шника будут и простые ошибки, и заковыристые. У C++ника простые ошибки поймает компилятор (при правильном использовании C++).
хотите верьте, хотите нет, имхо таким абстрактным спором мы не убедим друг друга..
думаете на C будут только простые ошибки — ну ваше право
P>>а как вы выразите бизнес логику без абстракций? Как на C, вы выразите сложение двух разряженный матриц? E>AddBlaBlaBlaMatrix( &matrix1, &matrix2 );
ну вот и я о том же — ну очень выразительно.
а теперь сложите три матрицы, умножьте на четвёртую, потом на вектор. да причём так, чтобы сложение трёх матриц было эффективным, не (первая + вторая)+третья, а именно одновременно.
на C++ можно делать так:
(m1+m2+m3)*m4*v1,
а что будет на C?
P>>А как вы делаете большие и средние проекты, если без абстракций? Каждый уровень абстракции увеличивает на порядок то, что можно выразить E>С уровням абстракции вроде как не мешает... Вообще, уровни абстракции -- это скорее к голове архитектора, а не к языку...
да, но в C++ больше средств выражения абстракций
и при этом они:
3. абстракции (зачастую абсолютно ничего не стоящие)
Здравствуйте, Piko, Вы писали:
P>>>а как вы выразите бизнес логику без абстракций? Как на C, вы выразите сложение двух разряженный матриц? E>>AddBlaBlaBlaMatrix( &matrix1, &matrix2 );
и кстати, что в вашем случае возвращает AddBlaBlaBlaMatrix ?
Здравствуйте, Piko, Вы писали:
P>Но, разве по вашему мнению C++ не позволяет писать более безопасные программы легче?
Фиг его знает. Нужна статистика по уязвимостям в С-программах и в С++
Я сильно не уверен, где ситуация будет хуже...
P>да, да, знаю такое мнение.
Это не мнение. Это факт.
Я выч. математик по образованию
P>
P>Because of the code reuse provided by generic programming, MTL has an order of magnitude fewer lines of code than the Netlib Fortran BLAS [20] | while providing much greater functionality and achieving signi cantly better performance. The MTL has 8,284
P>lines of code for its algorithms and 6,900 lines of code for its dense containers, while the Fortran BLAS total 154,495 lines of code. High performance versions of the BLAS (with which MTL is competitive) are even more verbose.
P>если надо, ещё подобных примеров приведу.
Ну так то таки FORTRAN, а не С даже... P>какова цена этих прекрасных библиотек на Fortran?
Ну их написали вполне подъёмные задачи оказались. Таки на FORTRAN вычматы писать проще, чем на С++, а там вообще с переиспользованием не всё хорошо.
P>а я говорю про С++, а не про его подмножество.
С++ в целом значительно сложнее и я не знаю что окажется дешевле, 154 КLOC на FORTRAN или 8 КLOC шаблонов С++.
Особенно, если ты не переписываешь уже распаханную вдоль и поперёк тему на шаблоны, и, таким образом, можешь заюзать команду классных программистов, а разрабатываешь библиотеку с нуля, то есть тебе нужны скорее спецы по ленейке и по архитектурам, а не по плюсам. То есть, что бы писать такую библу с нуля, нужно набрать каких-то классных вычматематиков, которые ещё и крутые С+ники, что может быть сколь угодно дороже, просто спецов в линейке, которые немного знают FORTRAN...
P>почему? очень яркий пример
Потому, что разговор о С++ vs С вообще ни о чём. Они слишком разные. Это типа как спрашивать, что лучше, джип или трактор. Где-то джип, а где-то трактор...
E>>Нет, не так. Если рассматривать всё в целом, то он нифига не обязательно ни более быстрый, ни более надёжный, ни с меньшим объёмом. P>нет, ну вот опять std::sort vs qsort, разве не так?
Не так. Либо ты юзаешь уродские STL'ные коллекции, либо пишешь свои, как минимум итераторы, либо работаешь на голых указателях. Так что упс, одновременно быстрее, надёжнее и компактнее не получится. Возможно получится выбрать какие-то два из трёх, и то я до конца не уверен
P>какие проблемы?
Что не получится...
P>где? и какой там контекст был?
Мне лень искать, где-то близко к корню этой ветки. И я не уверен до конца, что это был ты. Суть была такая, что задали фанатичным приверженцам С вопрос, почему таки С, а не подмножество С++?
P>каких гарантий нет в std::sort? в std::vector?
Да никаких нет. Сунь в std::vector std::auto_ptr и узнаешь, есть гарантии или как
P>>>ну реально подмножество С++ + тесты не особо лучше С + анализатор + тесты... E>>Такой вот вывод. Лучше, но в мелочах. А в чём-то хуже может быть.
P>выделенное вроде я не говорил
Да, это сбой КУВТа. Это я такой вывод делаю из обсуждения...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
MZ>>Конечно, С-шный код в принципе тоже может это соптимизнуть,
MZ>>но только это должен быть ОЧЕНЬ умный компилятор.
Не такой уж и умный, просто внутренняя функция. memcpy же оптимизируют...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Piko, Вы писали:
P>а теперь конкретно про тот пример, сколько кода добавится в вашем случае если нужно отсортировать ещё float'ы, double'ы, несколько структур? И сколько в случае C++?
и все три сортировки критичны по времени? Что это за программа такая?
Скорее всего критична какая-то одна, например float'ы. А остальные две пофигу как сортировать, то есть qsort...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
P>на C++ можно делать так: P>(m1+m2+m3)*m4*v1, P>а что будет на C?
О! Если ещё и лениво это всё делать... там за фасадом такое пиршество духа....
И чем мешает написать функцию Сделать_Нужное_Нам_Вычисление(v1,m4,m1,m2,m3,...) без всякой магии и предельно оптимально? Например с распараллеливанием по ядрам и/или поддержкой разреженных матриц?! Или это всё про сферического коня в вакууме?
Здравствуйте, Piko, Вы писали:
P>у C-шника будут и простые ошибки, и заковыристые. У C++ника простые ошибки поймает компилятор (при правильном использовании C++). P>хотите верьте, хотите нет, имхо таким абстрактным спором мы не убедим друг друга.. P>думаете на C будут только простые ошибки — ну ваше право
Да нет, С++ убьёт некий класс простых ошибок, которые, кстати, часто ловятся анализаторами или тестами, зато добавит сложных, специфически приплюснутых. С-то прост, как барабан, а вот про С++ так не скажешь...
E>>AddBlaBlaBlaMatrix( &matrix1, &matrix2 );
P>ну вот и я о том же — ну очень выразительно.
А что тут не понятно?
IMHO, очень даже выразительно.
P>а теперь сложите три матрицы, умножьте на четвёртую, потом на вектор. да причём так, чтобы сложение трёх матриц было эффективным, не (первая + вторая)+третья, а именно одновременно. P>на C++ можно делать так: P>(m1+m2+m3)*m4*v1, P>а что будет на C?
На С++ это будет эффективно, если повезёт, там автор класса матриц не заленится прикрутить шаблоны выражений, а потом все эти шаблонные навороты не дадут осечки, и компилятор не слажает и оптимизатор и т. д...
А вот на С будет CUDAшное ядро и соотвтествующий вызов...
P>да, но в C++ больше средств выражения абстракций P>и при этом они: P>
P>3. абстракции (зачастую абсолютно ничего не стоящие)
Ну в С средств УЖЕ ДОСТАТОЧНО. Проверено опытом программирования. В С++ их намного больше и они лучше, только часто всё равно абстракции задачи не хотят ложиться на абстракции С++, и всё равно слои дырявые выходят...
У С свои проблемы, у С++ -- свои. Но и та и другая машина ездят.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>И чем мешает написать функцию Сделать_Нужное_Нам_Вычисление(v1,m4,m1,m2,m3,...) без всякой магии и предельно оптимально? Например с распараллеливанием по ядрам и/или поддержкой разреженных матриц?! Или это всё про сферического коня в вакууме?
Речь про другое. Что мы что-то автоматизируем. То есть мы типа берём какие-то матрицы, как-то их хаполняем, пишем какие-то выражения, почти, как на доске или в блокное и чего-то там получаем.
только так не выходит, ручками всё равно выходит лучше пока что.
А если не ручками, а нормально оптимизировать матричные вычисления надо, то это не в С++ надо, а в вольфрам-математику...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
P>>Because of the code reuse provided by generic programming, MTL has an order of magnitude fewer lines of code than the Netlib Fortran BLAS [20] | while providing much greater functionality and achieving signi cantly better performance. The MTL has 8,284
P>>lines of code for its algorithms and 6,900 lines of code for its dense containers, while the Fortran BLAS total 154,495 lines of code. High performance versions of the BLAS (with which MTL is competitive) are even more verbose.
P>>если надо, ещё подобных примеров приведу. E>Ну так то таки FORTRAN, а не С даже...
И какой вывод из этого?
На C кода может быть даже больше
P>>какова цена этих прекрасных библиотек на Fortran? E>Ну их написали вполне подъёмные задачи оказались.
если есть 1e9$ многие задачи становятся подъёмными
E>Таки на FORTRAN вычматы писать проще, чем на С++, а там вообще с переиспользованием не всё хорошо.
вы понимаете, что если C++ позволяет писать более выразительные вычислительные алгоритмы, которые по скорости не уступают Fortran'у, то C тут вообще делать нечего
P>>а я говорю про С++, а не про его подмножество. E>С++ в целом значительно сложнее и я не знаю что окажется дешевле, 154 КLOC на FORTRAN или 8 КLOC шаблонов С++. E>Особенно, если ты не переписываешь уже распаханную вдоль и поперёк тему на шаблоны, и, таким образом, можешь заюзать команду классных программистов, а разрабатываешь библиотеку с нуля, то есть тебе нужны скорее спецы по ленейке и по архитектурам, а не по плюсам. То есть, что бы писать такую библу с нуля, нужно набрать каких-то классных вычматематиков, которые ещё и крутые С+ники, что может быть сколь угодно дороже, просто спецов в линейке, которые немного знают FORTRAN...
Тут вопрос в то что возможно ли вообще или нет.
C++ на порядок по объёму кода смог обогнать Fortran, специально заточенный под вычисления.
С тут и рядом не стоит.
P>>почему? очень яркий пример E>Потому, что разговор о С++ vs С вообще ни о чём. Они слишком разные. Это типа как спрашивать, что лучше, джип или трактор. Где-то джип, а где-то трактор...
ну особенно учитывая что большая часть C входит в C++
E>>>Нет, не так. Если рассматривать всё в целом, то он нифига не обязательно ни более быстрый, ни более надёжный, ни с меньшим объёмом. P>>нет, ну вот опять std::sort vs qsort, разве не так? E>Не так. Либо ты юзаешь уродские STL'ные коллекции, либо пишешь свои, как минимум итераторы, либо работаешь на голых указателях. Так что упс, одновременно быстрее, надёжнее и компактнее не получится. Возможно получится выбрать какие-то два из трёх, и то я до конца не уверен
При чём тут указатели? Фишка в том что операции над итераторами мэпятся в одну-несколько ассемблеровских инструкций
Вы листинг посмотрите.
E>>>Но я считаю, что это проблемы не всего С++, а конкретно STL. P>>какие проблемы? E>Что не получится...
что не получится?
P>>каких гарантий нет в std::sort? в std::vector? E>Да никаких нет. Сунь в std::vector std::auto_ptr и узнаешь, есть гарантии или как
не было встроенного (был "не встроенный") move синтаксиса, и что?
это место конкретно косяк auto_ptr, а не vector.
в новом стандарте, уже есть и move, и unique_ptr
Здравствуйте, Erop, Вы писали:
P>>а теперь конкретно про тот пример, сколько кода добавится в вашем случае если нужно отсортировать ещё float'ы, double'ы, несколько структур? И сколько в случае C++? E>и все три сортировки критичны по времени? Что это за программа такая? E>Скорее всего критична какая-то одна, например float'ы. А остальные две пофигу как сортировать, то есть qsort...
так зачем вообще платить больше, если автоматом можно получить быстрее?
Здравствуйте, Alexéy Sudachén, Вы писали:
P>>на C++ можно делать так: P>>(m1+m2+m3)*m4*v1, P>>а что будет на C? AS>О! Если ещё и лениво это всё делать... там за фасадом такое пиршество духа....
естественно лениво
как не лениво получить вот это:
да причём так, чтобы сложение трёх матриц было эффективным, не (первая + вторая)+третья, а именно одновременно.
?
AS>И чем мешает написать функцию Сделать_Нужное_Нам_Вычисление(v1,m4,m1,m2,m3,...) без всякой магии и предельно оптимально? Например с распараллеливанием по ядрам и/или поддержкой разреженных матриц?! Или это всё про сферического коня в вакууме?
ага, на каждое вычисление, под каждого пользователя писать MakeMeHappyX(...), а потом когда будет новый instruction set заново переписывать абсолютно всё
Здравствуйте, Erop, Вы писали:
P>>а теперь сложите три матрицы, умножьте на четвёртую, потом на вектор. да причём так, чтобы сложение трёх матриц было эффективным, не (первая + вторая)+третья, а именно одновременно. P>>на C++ можно делать так: P>>(m1+m2+m3)*m4*v1, P>>а что будет на C? E>На С++ это будет эффективно, если повезёт, там автор класса матриц не заленится прикрутить шаблоны выражений, а потом все эти шаблонные навороты не дадут осечки, и компилятор не слажает и оптимизатор и т. д... E>А вот на С будет CUDAшное ядро и соотвтествующий вызов...
ога, CUDA/OpenCL ведь только для C доступны...
Шаблонами выражений можно генерировать OpenCL ядра под конкретные выражение, а кого на этот раз позовёт C ?
Здравствуйте, Erop, Вы писали:
AS>>И чем мешает написать функцию Сделать_Нужное_Нам_Вычисление(v1,m4,m1,m2,m3,...) без всякой магии и предельно оптимально? Например с распараллеливанием по ядрам и/или поддержкой разреженных матриц?! Или это всё про сферического коня в вакууме? E>Речь про другое. Что мы что-то автоматизируем. То есть мы типа берём какие-то матрицы, как-то их хаполняем, пишем какие-то выражения, почти, как на доске или в блокное и чего-то там получаем. E>только так не выходит, ручками всё равно выходит лучше пока что. E>А если не ручками, а нормально оптимизировать матричные вычисления надо, то это не в С++ надо, а в вольфрам-математику...
кстати, раз вы вычмат, вы пробовали Blitz++/uBlas/Eigen/etc ?
И всё равно не выходит?
Здравствуйте, Piko, Вы писали:
P>какие-именно вычматы? зубочистки на 40 строк?
Ну по линейке любые...
P>Тут вопрос в то что возможно ли вообще или нет. P>C++ на порядок по объёму кода смог обогнать Fortran, специально заточенный под вычисления. P>С тут и рядом не стоит.
FORTRAN заточен на вычисления, а не на экономию объёма кода..
Но сама по себе цель экономии объёма не понятная. Понятная экономия поддержки, разработки и т. д...
P>При чём тут указатели? Фишка в том что операции над итераторами мэпятся в одну-несколько ассемблеровских инструкций P>Вы листинг посмотрите.
При том, что если у тебя есть какие-то свои быстрые коллекции, например, то тебе не получится засунуть их в std::sort, пока не припишешь к ним итераторы...
P>не было встроенного (был "не встроенный") move синтаксиса, и что?
и то, что прога упадёт в RT без всяких предупреждений и гарантий...
P>это место конкретно косяк auto_ptr, а не vector.
Это место -- косяк шаблонов, как концепции. ОНИ НЕ МОГУТ ДАТЬ НИКАКИХ ГАРАНТИЙ...
так же как и макросы, например.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Piko, Вы писали:
P>ога, CUDA/OpenCL ведь только для C доступны... P>Шаблонами выражений можно генерировать OpenCL ядра под конкретные выражение,
Просим! Просим!
P>а кого на этот раз позовёт C ?
Никого, поросто руками ядро прогер напишет и всё. А для того, что бы писать скрипты с плюсиками в матрицах есть более другие средства, чем С/С++
МатКад, например
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Piko, Вы писали:
P>кстати, раз вы вычмат, вы пробовали Blitz++/uBlas/Eigen/etc ? P>И всё равно не выходит?
Когда я ещё вычматами занимался, этого всего, как и нормального С++ не было...
А сейчас я в AI давно переквалифицировался, и тут С++ рулит, конечно, но С++ без фанатизма
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
P>>Тут вопрос в то что возможно ли вообще или нет. P>>C++ на порядок по объёму кода смог обогнать Fortran, специально заточенный под вычисления. P>>С тут и рядом не стоит. E>FORTRAN заточен на вычисления, а не на экономию объёма кода.. E>Но сама по себе цель экономии объёма не понятная. Понятная экономия поддержки, разработки и т. д...
Я вам объяснял пункты про скорость и объём кода
P>>При чём тут указатели? Фишка в том что операции над итераторами мэпятся в одну-несколько ассемблеровских инструкций P>>Вы листинг посмотрите. E>При том, что если у тебя есть какие-то свои быстрые коллекции, например, то тебе не получится засунуть их в std::sort, пока не припишешь к ним итераторы...
ну и?
P>>не было встроенного (был "не встроенный") move синтаксиса, и что? E>и то, что прога упадёт в RT без всяких предупреждений и гарантий... P>>это место конкретно косяк auto_ptr, а не vector. E>Это место -- косяк шаблонов, как концепции. ОНИ НЕ МОГУТ ДАТЬ НИКАКИХ ГАРАНТИЙ... E>так же как и макросы, например.
как никаких? вернёмся к std::sort и qsort, разве std::sort не даёт больше гарантий?
и да, они не защищают абсолютно ото всех ошибок
Здравствуйте, Piko, Вы писали:
P>как никаких? вернёмся к std::sort и qsort, разве std::sort не даёт больше гарантий?
Нет, конечно. qsort, как минимум не будет копировать компаратор, потому, что у него есть только указатель на функцию...
P>и да, они не защищают абсолютно ото всех ошибок
В среднем интерфейс шаблонов гарантирован и специфицирован хуже, чем интерфейс функций. И формально проверить его соблюдение тоже сложенее
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
P>>ога, CUDA/OpenCL ведь только для C доступны... P>>Шаблонами выражений можно генерировать OpenCL ядра под конкретные выражение, E>Просим! Просим!
на каждое встретившееся выражение напишет? А потом каждое перепишет на новую архитектуру?
ну так я о том и говорю, кода на порядки больше.
E>А для того, что бы писать скрипты с плюсиками в матрицах есть более другие средства, чем С/С++ E>МатКад, например
Ага, вот купил чувак допустим ansys, и solver ему говорит: "ты скопируй пожалуйста вот эти матрицы, вектора и выражения в MathCad, а мне результат скажешь".
Я это к тому, матрицы и в программах нужны, и конечный пользователь может даже не догадываться что они там есть.
offtopic: для matlab'а сейчас очень много решений на gpgpu появилось
Здравствуйте, Erop, Вы писали:
P>>как никаких? вернёмся к std::sort и qsort, разве std::sort не даёт больше гарантий? E>Нет, конечно. qsort, как минимум не будет копировать компаратор, потому, что у него есть только указатель на функцию...
если нужен шаблонный sort, именно с указателем на компаратор, никто не мешает его написать, и причём проверка типов будет лучше чем у qsort, гарантий больше
P>>и да, они не защищают абсолютно ото всех ошибок E>В среднем интерфейс шаблонов гарантирован и специфицирован хуже, чем интерфейс функций. И формально проверить его соблюдение тоже сложенее
Сейчас фактически спецификацией интерфейсов шаблонов является их код.
Но, даже в C++98 можно использовать ограниченные Constraints/ConceptsCheck .
И надеюсь в скором будущем появятся полноценные концепции.
Вот вы кстати упоминали динамические языки в соседней теме.
Во многих из них есть точно такой же duck-typing, но в C++ этот duck-typing времени компиляции, а не исполнения.
