Вообще-то при сравнении строк сравнивать первым делом их длину как-то не очень умно, "abcdefghij" < "cdefghij", причём длина?.. Да и немного настораживает уверенность по поводу реализации различных алгоритмов в стандартных бибилиотеках разных производителей... Попахивает ОБС (Одна Баба Сказала). Что касается сравнения строк, тоя  уже писал, что strcmp убивает string::compare в десятки раз... qsort- сильно зависит от того, что сортируем, все возмножные варианты не перебрать, но специалдьно для тебя проведу пару тестов и отпишусь. 

Добавлено @ 17:25


Ясно... Человек, который знает всё- глупец, не спорь с ним... 

Извиняюсь, что пронёс полную ахинею по поводу C... Ты во всём абсолютно прав! Я беру трубку и идут курить в корридоре...  

Добавлено @ 17:26


О чём здесь говорил, знаю и использовал неоднократно! "Прекрасно" C++ не знаю и никогда не узнаю. Во-первых, это невозможно, во-вторых, у меня другие интересы в программировании.

Добавлено через 9 минут и 19 секунд


Хотя бы просто потому, что "хорошая библиотека Qt"- это очень спорный вопрос. Кому-то нравится, кому-то совсем наоборот. Можно привести и wx, но и здесь всё очень спорно. А по поводу .NET я ни слова не сказал, что это "хорошая" технология!

Это сообщение отредактировал(а) HellStranger - 2.8.2010, 17:27

HellStranger, давайте соревнование замутим? реализуем какой-нить простенький алгоритмик типа вычисления множества мандельброта, вы на Сях или чем хотите, и я на С++ или чем захочу?)
потом сравним производительность и LOC (объем кода)

Хоть я и обещал не отвечать на ваши посты, но так уж и быть...

Только в свободное от проектов время, а это будет не раньше сентября. Так как за соревнования заказчик, к сожалению, не платит. А работа дороже...
Так как неоднократно поднимался вопрос о стандартной библиотеке C и stl. Предлагаю на этом и сконцентрировавть внимание. Всевозможные сравнения строк, поиски подстрок и т.д. и т.п. Сортировки наборов различных структур данных, ну и что ещё в голову взбредёт. 
Реализовывать рекурсивные алгоритмы, да, если ещё с отрисовкой- это больше смахивает на "у меня длиннее", а не на сравнение языков.
Продолжая тему, могу вам предложить реализовать простенький видеоредактор с базовым функционалом: я буду использовать сишный FFMPEG, а вы- что найдёте из cpp. 

Так что: базовые алгоритмы CRT и аналоги из STL. На паре-тройке компиляторов. Смогу начать уже сказал когда. До этого момента я даже сортировку пузырьком писать не буду...

Это сообщение отредактировал(а) HellStranger - 2.8.2010, 18:38

слово "хорошая" было поставлено в противовес выделенному 
а Qt привел в пример не потому то, она такая хорошая, а потому, что в отличие от .Net свободная
в том плане, что 
1. хотя и требует тоже специфических особенностей, но позволяет пользовать обычный (не специфический) компилятор
2. доступна  значительно более, чем на одной платформе
3. необъективно: приятна и логична в освоении.. 

Это сообщение отредактировал(а) mes - 2.8.2010, 20:35

по поводу С vs. C++

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

если использовать С++ просто как "С с классами", то там нет практически ничего, что может затормозить процесс выполнения

другой вопрос, что С++ объективно нагружен, сложен и костылеобразен, имеет абстрактный стандарт, который в реальной жизни не выполняет свою функцию...поэтому многие выбирают С: простой и понятный

я уже много раз повторял, что парадигма программирования и конкретный язык - это разные вещи
значительно упрощать себе жизнь на С помогает и ООП как _подход_ и _огромное_ множество (не сравнимое с С++) библиотек (кстати, из-за специфических возможностей С++ типа перегрузки)

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

В топку видеоредакторы, это весьма скучно и рутинно, к тому же решения будут базироваться на сторонних библиотеках - в итоге просто сравниваются библитотечные пиписьки. Предлагаю наколбасить по парсеру. Используем стандартные библиотеки (C99 - libc, C++03 - libc и libstdc++), всяким генераторам - нет. О входном языке можно договориться, о модулях (собсно парсер, оптимизатор, генератор кода/интерпретатор) - тоже; при подведении итогов сравниваются объем кода (меньше - лучше), его простота (проще - лучше), простота внесения новых языковых конструкций и прочих фич (к модулям, если будет что-то кроме парсера) (проще - заeбатее), производительность (скорость, память), что-нибудь еще? Заведомо субъективные оценки выносим на голосование.

Это сообщение отредактировал(а) djamshud - 2.8.2010, 22:11

djamshud, 
идея "соревнований" обречена на нереализацию ;)
проверено практикой

Естественно! Почему я приводил в пример PWLib, OPAL и старенький уже OpenH323. С++ используется просто как язык, поддерживающий ООП... ну и операторы переопределяются многие. Разработана вполне понятная, логичная архитектура классов, вся реализация которой- чистый C. 



Да вопрос даже скорее не в том, какой язык быстрее, в конце-концов это действительно зависит от многих факторов. Просто реально хочется проверть настолько ли хорошо stl, как его малюют. По крайней мере в работе со строками реально от отдыхает по сравнению с библиотекой C.



Реализовывать круптые поделухи, я думаю, ни у кого особого желания нет, по крайней мере у меня и времени нет. А что-нибудь простенькое для сравнения CRT и stl- я только за. Пусть и другие заинтересованные лица подпрягаются. Обсудим, что будем сравнивать и как.

Добавлено @ 22:44


Прошу обратить внимание, что библиотечные пиписьки я указывал сишные и пипишные. Как нельзя лучше отвечает предмету нашего соревнования. ) Это во-первых. Во-вторых, когда сварганишь редактор и пережмёшь им пару сотен фильмов, поизголяешься над звуковыми пакетами в .mov и профилях H264 и AAC, тогда и скажешь, что скучно и рутинно. По-моему, очень интересная область программирования. В-третьих, неужели у программистов есть время на то, чтобы реально меряться письками?.. Наряду с рабочими проектами можно найти море сторонних проектов, чтобы на маслице и икорочку к хлебу заработать... когда здесь меряться?..

Это сообщение отредактировал(а) HellStranger - 2.8.2010, 22:57

учится, учится, еще раз учится (с) дядя ленин.


через попу.
т.к. написано огромное кол-во оберток на с++, потому как с интерфейсами на Си работать можно как написано выше..

Добавлено через 1 минуту и 36 секунд

естественно. когда ядра начнут писать на с++, тогда Си стал бы оберткой.

Добавлено через 4 минуты и 18 секунд

наследуемся от std::string, добавляем свойство - _хеш_сумму_, и вуаля! сравнение за один машинный такт! это же очевидно 

Добавлено через 6 минут и 25 секунд


вы столько времени тратите на флуд, что можно было уже довольно крупный тест наваять. по крайней мере на С++, за, к примеру, час  

Нет, через вполне понятные исходники и комменты к ним, а вот cpp-обёртки- это как раз и есть попа для тех, кому лень учиться, учиться и учиться языку C.  И будет тебе известно, работать с интерфейсами в C не многим сложнее, чем в cpp. C поддерживает COM, а COM-это интерфейсы. 

это чё?

т.е. вы хотите сказать, что выучить Си сложнее?  лжец!

Ага, в 12 ночи сел ваять. ;)



И это я флудер...  У меня по дискретке хорошо профессор говорил: "Нечем заняться, не делай этого здесь." От тебя уже реально один бред пошёл...

Если быть точным - в пять:Правда, я имел в виду сравнение на равенство, операторами == и !=. Только в их случае имеет смысл сравнивать длину.

Если ваша программа (данные+функции) написана на Си и вам понадобилось внедрить ваш код в многопоточное приложение, то у вас начнутся проблемы (не нерешаемые, но всё же ...)
Если ваша программа написана на Си++ и вам надо перевести её на Си (для использования в каком-нибудь контроллере, например), то у вас тоже будут проблемы.
Вывод: edem das zaine (пардон за мой немецкий)
И ещё: если нужно написать программу с одной кнопкой, выводящей по нажатии на неё Хело Ворлд, то без использования визардов на Си уйдёт пару часов, на MFC - минут 20-30, на VCL или Qt - 2-3 минуты. Выводы делай сам

множественное наследование и dynamic_cast на Си покажите