а какая вероятность коллизий, кто-то может сказать? чувствую, что получится так, что она почти невероятна  

HellStranger, это была ирония. Почему никто этого не понял?.. :)

Добавлено через 3 минуты и 47 секунд
boostcoder, она маловероятна для десяти строк. Но вот же будет обидно, когда чудо-программа возьмет, да перепутает Васю с Маней. Какой бы малой эта вероятность ни была ее никак нельзя игнорировать.

Вообще-то, операции != и == имеют абсолютно одинаковую сложность. Так как != это инвертированный вариант ==. Т.е. если ты зафиксировал, что условие a != b не выполняется, то можно со 100% точностью сказать, что выполняется a == b. В нашем же случае, когда два хэша равны, это не значит что две строки равны. Это значит, что надо сравнить сами строки. И не важно для какого оператора - == или !=.

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

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

bsa, да, у меня мысля за мыслю зашла.

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

зато если хэши не равны, то однозначно не равны.. хотя в любом случае не аргумент.. 

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

а вот например как выглядит на С реализация автоматизации по технологии CopyOnWrite ?
или RAII ? 

Посмотри OpenSSL  

Имхо, это нереально.

какие?

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

не надобно из-за отсутствия исключений ;)

MAKCim, в Си могут быть исключения.
в винде например есть SEH\VEH + RaiseException()

Abyx, 
это не связано с языком как таковым

MAKCim, когда функции используют глобальные статические переменные и их потребовалось использовать в нескольких потоках - это проблема. У меня были случаи, когда dll-ки, написанные подобным образом на Си нужно было переименовывать в рантайме и загружать её копию в каждом потоке.
Конечно и на Си++ можно так писать, но процедурное программирование к этому больше располагает, чем классы

вы уверены что это нормальный способ? если длл - ваши, то более тупого решения не придумать %) для таких вещей есть TLS

Естественно, Вы тут самый умный, а все вокруг - полные идиоты.
Длл-ки были не мои. Предложи более правильный способ.

Знаете, по-моему это проблема называется- недостаточно хорошее продумывание архитектуры приложения. И, если C по-вашему виноват в том, что не предоставляет инструментария по вырыванию рук криворуким программистам, то уж извините... Не для этого он разрабатывался... 




А вот этов  чистом виде ОБС (Одна Баба Сказала). Так можно писать и на C#, и на Java и т.д. и т.п. Классы не заменят мозгов!




Я, конечно, далёк от вашей проблемы, но решение выбрано и в самом деле брутальное... Сродни разработчикам вашей пресловутой dll...

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


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

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


Поверьте, их может быть ОЧЕНЬ МНОГО! Только C как таковой здесь не причём... 

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

делать по длл на поток - это весьма расточительное использование памяти. разве что дллки очень маленькие.
впрочем переименовывать файл - это тоже сомнительное решение, из разряда "как умеем так и делаем".
так что 3й вариант, с копированием:

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