встроенных нет. но самому организовать тебе никто не запрещает   

bsa, я думаю вы понимаете, что это *много строк кода*
вернее *ОЧЕНЬ МНОГО СТРОК КОДА*

мой опыт работы с COM из асма показал что лучше использовать как минимум С++ и ATL 

Это сообщение отредактировал(а) Abyx - 3.8.2010, 10:27

HellStranger, тогда к чему вообще написание каких-то редакторов? Ищи по софтине с (примерно) аналогичным функционалом на разных языках и сравнивай. Можно найти кучу примеров как в пользу сишных поделок, так и плюсовых - в конечном счете все упирается в криворукость ваятелей каждого конкретного решения. Плюсы дают такой же простор для творчества и маневра, что и си, но предлагают больше слов для выражения своих идей, и, если ты путаешься в этих словах - ССЗБ, пиши на более простом си и трать на разработку больше времени, в противном случае получай как минимум тот же результат (хотя на деле результат скорее всего окажется более расширяемым и масштабируемым - но тут опять все зависит от криворукости) за умеренные сроки.

boostcoder, 

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

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

а что тут несерьезного? сложность в чем? точнее, в чем именно?

boostcoder, пример, пожалуйста. А там посмотрим, что за проблемы. Сколько уже можно теоретизировать?:)

В том, что методы сравнения у std::string как минимум не виртуальные. Т.е. наследованием ты тут не обойдешься - придется делать агрегацию и перенаписание всех методов заново. А потом, когда ты собрался считать хэш? на этапе присваивания/изменения значения? А ты не думал, что может оказаться такая ситуация, в которой есть куча смен значений и ни одного сравнивания? Кстати, хэш тебе не заменит compare.

Ну и ладно, теория тоже хорошо в конце концов.

1. Коллизии (потенциальные!). Что с ними делать?
2. Есть ли хеш-функции, гарантирующие, что хеш любой "меньшей" строки будет меньше хеша данной строки? Сомневаюсь.

потестить тут: http://liveworkspace.org/code/be1ad8c6bdca...15e8dd2119deb17


нет, я конечно подумал об этом. но раз HellStranger`а беспокоит производительность, значит ему нужно сравнивать не 5 строк. но если строк много, тысячи..сотни тысяч, то рассчитывать хешь нужно в момент "собирания" такого кол-ва строк. т.к. сложно представить источник, способный формировать, к примеру, мильён строк за 20мс.


смотря что ожидается от compare.

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

я так понял, разговор про operator==() и !=

Добавлено через 5 минут и 2 секунды
кстати, еще один тест: http://liveworkspace.org/code/6b5720fc2147...b8e099875da53d1
как видно из результата, сравнение стандартной строки, происходит в 6-7 раз дольше. профайлер говорит что все тормоза из-за функции(метода) __builtin_memcmp(). но я ее не нашел.

Добавлено через 5 минут и 48 секунд
зы
алгоритм подсчета хеш суммы, взят из википедии.

Если быть совсем точным, то зависит от компилятора и процессора, но суть Тела не меняет, правда ведь?.. 
Операторы сравнения: в C аналогов нету, смысл сравнивать?.. Или будем сравнивать указатели? 

Что касается qsort, то результат вас тоже не сильно обрадует... Хотя, сильно зависит от того, что сортировать...

Предлагаю! Всем заинтересованным в тесте людям, модераторам тоже! Реально заняться сравнением прелестей CRT и stl. Выработать ощий план: что сравниваем, как сравниваем, на чём сравниваем. Прок от этого, думаю, в любом случае будет: кто-то начнёт больше юзать CRT, а кто-то, возможно, обратит внимание на stl... 

Это сообщение отредактировал(а) HellStranger - 3.8.2010, 11:47

>я так понял, разговор про operator==() и !=

С ними весьма хорошо справляются и обычные сравнения длин + memcmp. Для сортировок нужно проверять на больше/меньше.

И таки что с коллизиями делять? (это когда у двух разных строк хеш-суммы совпадают (потенциально это может быть у любой пары строк)).

Добавлено через 4 минуты и 44 секунды
Я как бы намекаю, что сравнение строк по их хешу очень эффективно, когда идет речь о !=, а == - это сравнение хешей плюс сравнение самих строк.

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


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

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

вариант   

boostcoder, так вы признаете, что ваша реплика об однотактовом сравнении имеет смысл только для операции !=, а все остальные - ==, >, <, >=, <= - будут тупить и особого смысла применять к ним хеширование (внутри реализации класса "строка") нет? Или будете гуглить волшебные хеш-функции?:)

Да и между нами девочками, нехилые такие строки получаются... В C просто набор байт и ничего лишнего... А здесь уже нагородили хэш-таблицы, помимо своих охренительных прелестей std::string... А мне надо тупо сравнить "Вася Пупкин" с "Маша Залупкина"! Сейчас мы вооружимся ядерной боеголовкой производства boostcoder и Ёпнем по мухе!

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


А их нет и не может быть... Все алгоритмы подвержены коллизиям. Если мощность множества объектов, от которых будет вычисляться хэш больше мощности множества значений хэш-функции, а в нашем примере это так; то коллизии в любом случае есть и будут. Спорить собственно не о чем!

да  

буду. любопытно  


ничего не городил. стандартная таблица.


т.е. для сравнения двух строк, вас мегабесспокоит затрачиваемое время?  



  

boostcoder,

>буду. любопытно

Их нет. Можно нагородить тысячу костылей для адаптации хеш-суммы, если такая уже была однажды сгенерирована, но все эти проверки будут занимать уйму времени и памяти (ведь все нужно централизованно хранить, следить за созданием, изменением, удалением строк), а в конечном счете все равно рискуете упреться в потолок, когда весь спектр хеш-сумм будет задействован.