[c++] Почему в с++ нету

http://www.gnu.org/software/gsl/

можешь считать, что она стандартная

Это лишь одна из кучи реализаций. У каждого свои велосипеды. Почему нельзя было сделать это стандартизовано как со строками? Ведь это не Си.

есть еще boost.ublas - http://www.boost.org/doc/libs/1_43_0/libs/numeric/ublas/doc/index.htm

почти стандарт :-)

А если в гугле наберешь про матрицы вылезут с 10ток реализаций

>Это лишь одна из кучи реализаций. У каждого свои велосипеды. Почему нельзя было сделать это стандартизовано как со строками? Ведь это не Си.

Со строками тоже куча реализаций.

Со строками тоже куча реализаций.

Например?

Тогда почему есть string идущий в комплекте, а для матриц нужно ставить отдельно?

Ну хотя да, не куча, можно только QString вспомнить.

А матрицы — гораздо более редкая вещь, чем строки. Вот и нет в стандарте.

а почему там нет рациональных чисел? длинной арифметики? деревьев?

>Тогда почему есть string идущий в комплекте

Потому, что string применяют очень часто, а матрицы редко, и нет смысла загромождать им библиотеку.

ну нельзя же библиотеки на все случаи жизни включить в стандарт. он и так очень большой, больше 1,000 страниц если правильно помню. какая разница, какие проблемы слинковать любую понравившуюся библиотеку.

Есть же буст.

Type_t **var
чем не матрица?????

велосипед будешь строить

а почему там нет рациональных чисел? длинной арифметики? деревьев?

Где можно использовать рациональные числа?

Длинная арифметика действительно редко используется. А вот работа с матрицами очень даже не редкая вещь.

Есть ведь всякие vector, list, queue, map, set. Матрицы того же порядка.

Тогда такой вопрос: что выбрать gsl или boost?

если надо просто матрицы - то boost

Type_t **var

чем не матрица?????

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

говнокодер?

boost.ublas очень медленный.

Длинная арифметика действительно редко используется.

Криптография же ну.

оналитег?

Ок. Тогда такой аргумент. Во многих языках программирования матрица реализована как стандартная.

Во многих языках программирования матрица реализована как стандартная.

длинная арифметика - тоже. и рациональные числа

Да. И я умён. А тебе следует научиться работать с указателями и вообще осознать окружающий мир и ответственность за свои действия.

http://bash.org.ru/quote/405584

Давным-давно к Тэнь-Пу пришел ученик и спросил его о смысле плоти. Тэнь-Пу долго думал и сказал: есть ум. О плоти поговорим позже. Так вот, ум следует пополнять постоянно, и применять его тоже нужно постоянно. Более того, его нужно применять on demand, причем именно его, а не заменители. То есть ты делашь что-то, - ты должен знать и понимать, что ты при этом делаешь.

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

Например, как работает двигатель автомобиля ты знаешь. Все шурупы и винты запоминать нет смысла. А теперь надо поменять масло. Для этого вспоминать как устроен весь движок не надо, а лишь схематическое знания хватает.

Теперь возьмем матрицы:

Matrix a(n,m);
double **b;

только для доступа к элементам:

a(1,1);
b[(n-1)*1-1];

А теперь представь нужно тебе

a(n+m*k,n-m*k);
b[(n-1)*(n+m*k)+n-m*k]; И т.п.

Со строками тоже куча реализаций.

Например?

например в GCC std::string - это одно, а в MSVC - совсем другое, а кое где его может и не быть совсем

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

> например в GCC std::string - это одно, а в MSVC - совсем другое

ну так можно на что угодно ткнуть - у С тоже масса реализаций стандартной библиотеки

а кое где его может и не быть совсем

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

> а кое где его может и не быть совсем

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

с матрицами всё то же самое :) только, вследствие того что они реже используются, их не включают в состав стандартной библиотеки, и это правильно

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

очень толсто, сэр

так троллили, ещё в прошлом веке

Вместо того, чтобы взять хороший, в меру мощный и в меру скромный язык с хорошей органичной семантикой (Си), который есть не что иное как любой современный компьютер.

Выдыхай. Мне нужны классы, шаблоны, безопасная работа с указателями. Есть они в Си?

Неумение организовать код красиво ты стремишься компенсировать фичастостью используемых инструментов.

Не столько красота кода важна, сколько простота работы с ним.

>Есть ведь всякие vector, list, queue, map, set. Матрицы того же порядка.

Все вышеперечисленные контейнеры и адапторы я использую каждый день (ну разве что, list и queue — несколько реже). А вот за четыре года работы (domain: compilers, static code analyzers) классическая «прямоугольная» матрица мне так и не понадобилась. Да, в одном месте у меня используется самописная «разреженная» матрица (которая по сути — хэш-таблица, в которой ключом являются координаты ячейки), но это совсем другая структура данных.

Умеет ли gsl работать с ленточными матрицами?

Так что матрицы — совсем не «того же порядка».

>говнокодер?

Если человек не любит писать лишний и бесполезный код, без которого вполне можно было бы обойтись (а явный вызов оператора delete обычно таковым и является), то это как раз признак того, что он НЕ говнокодер, а человек разумный.

>Во многих языках программирования матрица реализована как стандартная.

А еще во многих языках программирования есть габадж коллектор. Но это ведь не повод пихать его в наш безупречный C++!

> Умеет ли gsl работать с ленточными матрицами?

да - http://www.gnu.org/software/gsl/manual/html_node/BLAS-Support.html

>> например в GCC std::string - это одно, а в MSVC - совсем другое

а кое где его может и не быть совсем

есть как минимум две годные реализации STL, не привязанные к компилятору

Ну если мне не изменяет память, то std::string не является частью STL

> Ну если мне не изменяет память, то std::string не является частью STL

да - я ерунду написал

Тогда почему нету его тут: http://www.gnu.org/software/gsl/manual/html_node/Cholesky-Decomposition.html

значит надо матрицу «перепаковать» в общий вид перед использованием с данной функцией

Тогда смысл его использовать нету.

есть, но не для всех задач

vector вполне подходит для матриц, тогда delete писать не придётся. всё равно если нужны матрицы, то их наверняка придется передавать во внешние либы (blas, lapack ...), а не использовать напрямую

Тебе изменяет мозг.

> Тебе изменяет мозг.

нет

>vector вполне подходит для матриц, тогда delete писать не придётся.

Не, ну речь была как бе не совсем об этом..

И, к слову, использовать вектор напрямую — тоже не комильфо, все равно нужна какая-то объектная обвертка над ним

Просто люди, которые в ответ на разумные утверждения о небезопасности и неудобстве работы напрямую с динамическим массивом памяти говорят «говнокодер!», несколько умиляют:).

Ладно бы если средства языка это не позволяли — но ведь у нас есть конструкторы/деструкторы, RAII и куча уже готовых механизмов в boost, Loki, C++0x standard library. Но нет же, предпочитают даже не изобретать велосипеды — а просто писать exception-unsafe код с потенциальными мемориликами, дедлоками и прочими проблемами, связанными с «забыванием» освобождения ресурсов.

всё равно если нужны матрицы, то их наверняка придется передавать во внешние либы (blas, lapack ...), а не использовать напрямую

Ну ничто не мешает при разработке класса для матрицы предусмотреть метод, возвращающий C-Style указатель на матрицу для работы с внешними либами.

> Мне нужны классы, шаблоны, безопасная работа с указателями. Есть они в Си?

Классы не нужны, есть структуры (ООП это brain damage). Шаблоны - полезно, но не так чтобы очень, есть void * (и вообще, есть лисп с действительно мощной макросистемой). Указатели - по определению суть адреса в адресном пространстве, чья семантика определяется средой выполнения конкретной реализации C или C++, во всех практических случаях это непосредственно хардварная адресация. То есть вещь по определению небезопасная, говорить о безопасности тут ваще не приходится. Вам трудно написать free()?

Не столько красота кода важна, сколько простота работы с ним.

Ну дык она вытекает из красоты кода. С говнокодом просто работать?