В плюсах не надо сношаться с ручными выделением/освобождением памяти и ресурсов. Есть удобная библиотека stl, не нужно сношаться со всякими мострами типа tree.h. В результате код получается короче, читабельнее, проще в отладке и местами даже быстрее.
это до тех пор пока не надо сделать что-то хоть немного нетривиальное
Да почти все так написано. Любой нетривиальный софт на Си достаточно взять, чтобы убедиться. Например ffmpeg. Там все типичные ужасы Си — лапша, страшное ОО, мышиная возня со всякими мелочами. В результате имеем нестабильную кучу говна, которая валится при малейшем чихе.
Любой нетривиальный софт на Си достаточно взять, чтобы убедиться. Например ffmpeg.
что там нетривиального? :) нетривиальная - это какая-нибудь система управления для АЭС, или что-то в этом роде, да хотя бэ linux kernel (у меня не падает :))
Работа с кучей форматов данных и протоколов + попытка обернуть это всё в единый OO API. В общем, попытка объять необъятное :)
или что-то в этом роде, да хотя бэ linux kernel
Ага, я недавно про inotify писал. А всё там видимо из-за того, что разработчикам лениво было гемороиться на Си со структурой данных под задачу и взяли уже готовое, со всеми вытекающими. Был бы в Си аналог STL'я можно был бы гораздо более широкий выбор структур данных или можно было гораздо быстрее из имеющихся кубиков смастерить структуру данных под задачу.
Работа с кучей форматов данных и протоколов + попытка обернуть это всё в единый OO API.
если С++ так хорош, почему не переписали на нём?
В общем, попытка объять необъятное :)
скорее уж запихнуть незапихуемое :)
Был бы в Си аналог STL'я можно был бы гораздо более широкий выбор структур данных или можно было гораздо быстрее из имеющихся кубиков смастерить структуру данных под задачу.
на количество доступных структур данных это бы никак не повлияло, скорость разработки на С++ выше, да
где альтернатива? и если ffmpeg такой кривой и плохой, почему им пользуются и сейчас?
Альтернативы, которая пытается объять необъятное, естественно, нет.
Но по разным частям ffmpeg'а есть альтернативы, например очень хороший клиент и сервер rtsp реализован в библиотеке live555. По многим параметрам он уделывает ffmpeg. Кстати, эта библиотека используется в vlc.
и что с того? сами структуры от этого не становятся недоступными, не так ли?
Так почему тогда в реализации inotify для хранения постоянно возрастающих дескрипторов взяли radix tree? Я уверен, что из-за того, что им лень было писать и отлаживать свою структуру данных.
Не было таких проблем. С кроссплатформенностью всё было гораздо гораздо лучше чем у gtk (как и сейчас, кстати). С лицензией тоже было всё однозначно. Либо не плати бабки и используй GPL либо плати бабки и используй неGPL.
Так почему тогда в реализации inotify для хранения постоянно возрастающих дескрипторов взяли radix tree?
очевидно потому, что там где можно разделить ключ поиска на разряды radix tree даёт хорошее время поиска, правда есть нюанс с тем, что если вставлять ключи последовательно дерево получится перекошенное на сторону, но это можно разрулить
и да, если всё так плохо, почему тогда в «любимом бусте» используются такие же деревья (see Boost.RegExp, могу указать точнее)?
очевидно потому, что там где можно разделить ключ поиска на разряды radix tree даёт хорошее время поиска, правда есть нюанс с тем, что если вставлять ключи последовательно дерево получится перекошенное на сторону, но это можно разрулить
Там ключ это постоянно возрастающий int, очевидно, что radix tree тут не подходит. Разрулить это можно либо сменой алгоритма генерации новых ключей либо сменой структуры данных для хранения ключей. А сейчас имеем то, что при интенсивной длительной работе приложение с inotify может поставить раком систему.
и да, если всё так плохо, почему тогда в «любимом бусте» используются такие же деревья (see Boost.RegExp, могу указать точнее)?
А я не говорю, что это плохо, просто их надо использовать к месту.
Там ключ это постоянно возрастающий int, очевидно, что radix tree тут не подходит. Разрулить это можно либо сменой алгоритма генерации новых ключей либо сменой структуры данных для хранения ключей.
не обязательно сменой структуры данных, к примеру есть механизм перемешивания (splaying), который перебалансирует дерево (к слову, в Boost.RegEx используется именно этот механизм :))
А я не говорю, что это плохо, просто их надо использовать к месту.
вот и я говорю что надо использовать к месту, а С++ то или С или Java - покласть
Бесполезный спор. Сейчас все равно все эти билиотеки типа Gtk+ & Qt будет вытеснять веб-библиотеки и HTML 5. Все программы постепенно переползают в веб.
Я например сейчас хочу изучить qooxdoo, на мой взгляд за ней есть будущее.
> Нативные приложения никуда не денутся, так как не все хотят отдавать результаты своего труда чужому дяде.
Ну это еще спору на 10 страниц. Могут удалить за флейм :)
Предлагаю остановиться. Хочет человек изучать Qt - пусть изучает. Для меня же предпочтительнее Gtk+, поскольку кроме Си я еще пишу на Perl, а Gtk2-Perl работает отлично под linux & win32.
> не обязательно сменой структуры данных, к примеру есть механизм перемешивания
Он поднимает часто используемые вершины на верх, не думаю, что тут может.
это зависит, но всё лучше будет чем сваленное набок дерево
и да, раз у них id выдаются подряд им не мешало бы чего придумать вменяемого, с другой стороны сваленное дерево даёт n*log(n) против log(n) не думаю фризы лезут именно с этой стороны
А почему у тебя в списке только Си-образные языки ? :)
локальный аттрактор :)
Я, кстати, сейчас в конторе пытаюсь схему внедрить для решения одной мега-задачи :)
да я и сам clojure собираюсь заюзать в новом проекте, надоело одно и то же долбить, хочется праздника :)
Звучит как хочу накачать большие мускулы. Хочешь изучить Qt - изучай: пиши, отлаживай и совершенствуй программы, а в качестве литературы http://doc.qt.nokia.com/4.7/index.html (или любая книга, в названии которой есть Qt).
«дайте шоле» блин... Шлее хорошая книга. Бланшет - отстой. Ещё недавно вышла книга Саммерфилда, но это уже для тех у кого опыт есть. А вообще QtAssistant. Там ещё примеров много можно найти) Вообще справка отличная)