LINUX.ORG.RU

Ответ на: комментарий от Reset

В плюсах не надо сношаться с ручными выделением/освобождением памяти и ресурсов. Есть удобная библиотека stl, не нужно сношаться со всякими мострами типа tree.h. В результате код получается короче, читабельнее, проще в отладке и местами даже быстрее.

это до тех пор пока не надо сделать что-то хоть немного нетривиальное

shty ★★★★★
()
Ответ на: комментарий от Reset

Нетривиальное на Си превращается либо в лапшу либо в страшные OO ужасы типа gtk.

вовсе и нет, это зависит от квалификации писавшего

shty ★★★★★
()
Ответ на: комментарий от shty

Да почти все так написано. Любой нетривиальный софт на Си достаточно взять, чтобы убедиться. Например ffmpeg. Там все типичные ужасы Си — лапша, страшное ОО, мышиная возня со всякими мелочами. В результате имеем нестабильную кучу говна, которая валится при малейшем чихе.

Reset ★★★★★
()
Ответ на: комментарий от Reset

Да почти все так написано.

много, не не «почти всё»

Любой нетривиальный софт на Си достаточно взять, чтобы убедиться. Например ffmpeg.

что там нетривиального? :) нетривиальная - это какая-нибудь система управления для АЭС, или что-то в этом роде, да хотя бэ linux kernel (у меня не падает :))

shty ★★★★★
()
Ответ на: комментарий от shty

что там нетривиального?

Работа с кучей форматов данных и протоколов + попытка обернуть это всё в единый OO API. В общем, попытка объять необъятное :)

или что-то в этом роде, да хотя бэ linux kernel

Ага, я недавно про inotify писал. А всё там видимо из-за того, что разработчикам лениво было гемороиться на Си со структурой данных под задачу и взяли уже готовое, со всеми вытекающими. Был бы в Си аналог STL'я можно был бы гораздо более широкий выбор структур данных или можно было гораздо быстрее из имеющихся кубиков смастерить структуру данных под задачу.

Reset ★★★★★
()
Ответ на: комментарий от Gorthauer

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

you caught it :)

//there is no silver bullet

shty ★★★★★
()
Ответ на: комментарий от Reset

Работа с кучей форматов данных и протоколов + попытка обернуть это всё в единый OO API.

если С++ так хорош, почему не переписали на нём?

В общем, попытка объять необъятное :)

скорее уж запихнуть незапихуемое :)

Был бы в Си аналог STL'я можно был бы гораздо более широкий выбор структур данных или можно было гораздо быстрее из имеющихся кубиков смастерить структуру данных под задачу.

на количество доступных структур данных это бы никак не повлияло, скорость разработки на С++ выше, да

shty ★★★★★
()
Ответ на: комментарий от shty

если С++ так хорош, почему не переписали на нём?

у разработчиков ffmpeg'а с головой не все в порядке, что как раз подтверждают последние события вокруг этого проекта

на количество доступных структур данных это бы никак не повлияло

на си их пришлось бы писать с нуля

Reset ★★★★★
()
Ответ на: комментарий от Reset

> если С++ так хорош, почему не переписали на нём?

у разработчиков ffmpeg'а с головой не все в порядке, что как раз подтверждают последние события вокруг этого проекта

где альтернатива? и если ffmpeg такой кривой и плохой, почему им пользуются и сейчас?

> на количество доступных структур данных это бы никак не повлияло

на си их пришлось бы писать с нуля

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

PS структуры данных - это пара процентов от времени разработки

shty ★★★★★
()

Макс Шлее + официальная документация

Divius ★★
()
Ответ на: комментарий от jtootf

Любой биндинг к кути помимо питона так можно обозвать.

tensai_cirno ★★★★★
()
Ответ на: комментарий от shty

где альтернатива? и если ffmpeg такой кривой и плохой, почему им пользуются и сейчас?

Альтернативы, которая пытается объять необъятное, естественно, нет. Но по разным частям ffmpeg'а есть альтернативы, например очень хороший клиент и сервер rtsp реализован в библиотеке live555. По многим параметрам он уделывает ffmpeg. Кстати, эта библиотека используется в vlc.

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

Так почему тогда в реализации inotify для хранения постоянно возрастающих дескрипторов взяли radix tree? Я уверен, что из-за того, что им лень было писать и отлаживать свою структуру данных.

Reset ★★★★★
()

Хочу выпить пива.

Дайте денег на пиво штоле;/

Dikar ★★
()
Ответ на: комментарий от Mrak

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

Так почему тогда в реализации inotify для хранения постоянно возрастающих дескрипторов взяли radix tree?

очевидно потому, что там где можно разделить ключ поиска на разряды radix tree даёт хорошее время поиска, правда есть нюанс с тем, что если вставлять ключи последовательно дерево получится перекошенное на сторону, но это можно разрулить

и да, если всё так плохо, почему тогда в «любимом бусте» используются такие же деревья (see Boost.RegExp, могу указать точнее)?

shty ★★★★★
()
Ответ на: комментарий от shty

очевидно потому, что там где можно разделить ключ поиска на разряды radix tree даёт хорошее время поиска, правда есть нюанс с тем, что если вставлять ключи последовательно дерево получится перекошенное на сторону, но это можно разрулить

Там ключ это постоянно возрастающий int, очевидно, что radix tree тут не подходит. Разрулить это можно либо сменой алгоритма генерации новых ключей либо сменой структуры данных для хранения ключей. А сейчас имеем то, что при интенсивной длительной работе приложение с inotify может поставить раком систему.

и да, если всё так плохо, почему тогда в «любимом бусте» используются такие же деревья (see Boost.RegExp, могу указать точнее)?

А я не говорю, что это плохо, просто их надо использовать к месту.

Reset ★★★★★
()
Ответ на: комментарий от Reset

Там ключ это постоянно возрастающий int, очевидно, что radix tree тут не подходит. Разрулить это можно либо сменой алгоритма генерации новых ключей либо сменой структуры данных для хранения ключей.

не обязательно сменой структуры данных, к примеру есть механизм перемешивания (splaying), который перебалансирует дерево (к слову, в Boost.RegEx используется именно этот механизм :))

А я не говорю, что это плохо, просто их надо использовать к месту.

вот и я говорю что надо использовать к месту, а С++ то или С или Java - покласть

shty ★★★★★
()
Ответ на: комментарий от shty

не обязательно сменой структуры данных, к примеру есть механизм перемешивания

Он поднимает часто используемые вершины на верх, не думаю, что тут может.

вот и я говорю что надо использовать к месту, а С++ то или С или Java - покласть

А почему у тебя в списке только Си-образные языки ? :) Я, кстати, сейчас в конторе пытаюсь схему внедрить для решения одной мега-задачи :)

Reset ★★★★★
()
Ответ на: комментарий от Reset

qooxdoo

Бесполезный спор. Сейчас все равно все эти билиотеки типа Gtk+ & Qt будет вытеснять веб-библиотеки и HTML 5. Все программы постепенно переползают в веб.

Я например сейчас хочу изучить qooxdoo, на мой взгляд за ней есть будущее.

Mrak ★★★
()
Ответ на: qooxdoo от Mrak

Бесполезный спор. Сейчас все равно все эти билиотеки типа Gtk+ & Qt будет вытеснять веб-библиотеки и HTML 5.

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

Ну это еще спору на 10 страниц. Могут удалить за флейм :)

Предлагаю остановиться. Хочет человек изучать Qt - пусть изучает. Для меня же предпочтительнее Gtk+, поскольку кроме Си я еще пишу на Perl, а Gtk2-Perl работает отлично под linux & win32.

Mrak ★★★
()
Ответ на: комментарий от Reset

> не обязательно сменой структуры данных, к примеру есть механизм перемешивания

Он поднимает часто используемые вершины на верх, не думаю, что тут может.

это зависит, но всё лучше будет чем сваленное набок дерево

и да, раз у них id выдаются подряд им не мешало бы чего придумать вменяемого, с другой стороны сваленное дерево даёт n*log(n) против log(n) не думаю фризы лезут именно с этой стороны

А почему у тебя в списке только Си-образные языки ? :)

локальный аттрактор :)

Я, кстати, сейчас в конторе пытаюсь схему внедрить для решения одной мега-задачи :)

да я и сам clojure собираюсь заюзать в новом проекте, надоело одно и то же долбить, хочется праздника :)

shty ★★★★★
()

>Хочу изучить Qt

Звучит как хочу накачать большие мускулы. Хочешь изучить Qt - изучай: пиши, отлаживай и совершенствуй программы, а в качестве литературы http://doc.qt.nokia.com/4.7/index.html (или любая книга, в названии которой есть Qt).

Genuine ★★★
()

«дайте шоле» блин... Шлее хорошая книга. Бланшет - отстой. Ещё недавно вышла книга Саммерфилда, но это уже для тех у кого опыт есть. А вообще QtAssistant. Там ещё примеров много можно найти) Вообще справка отличная)

kpx13
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.