| Вопрос: Вопрос наоборот | Добавлено: 25.01.05 22:56 |
Автор вопроса:  cresta
|
| Ответы | Всего ответов: 31 |
|
Номер ответа: 16 Автор ответа:  sne Разработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445 |
Web-сайт: Профиль | | #16 | Добавлено: 26.01.05 21:57 |
2CyRax - .486, привык просто, рука сама пишет 
|
||
|
Номер ответа: 17 Автор ответа: crestaВопросов: 117 Ответов: 1538 |
Профиль | | #17 | Добавлено: 26.01.05 22:29 |
| Чуток потестил: Если самому делать SysAllocStringByteLen, и возвращать готовую BSTR, (т.е. ф-ция объявлена As String) то получается (при разных условиях) от 20 до 30% быстрее, чем делать буфер String(Const,Chr(0)). | ||
|
Номер ответа: 18 Автор ответа: sneРазработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445 |
Web-сайт: Профиль | | #18 | Добавлено: 27.01.05 02:04 |
|
Урря товарищи А SysAlloc не пробовал ?
|
||
|
Номер ответа: 19 Автор ответа: crestaВопросов: 117 Ответов: 1538 |
Профиль | | #19 | Добавлено: 27.01.05 02:42 |
|
SysAllocString что-ли? Пробовал, с ней выигрыш маленький - ок.5-7%.
Да и от SysAllocStringByteLen ожидал большего выигрыша, чем 20-30%  Но один оч.удобный момент все-же есть: нет необходимости заранее знать, сколько будет длина строки.
|
||
|
Номер ответа: 20 Автор ответа: sneРазработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445 |
Web-сайт: Профиль | | #20 | Добавлено: 27.01.05 03:14 |
|
просто я к тому что SysAllocString он работает с юникод строками, а вот SysAllocStringByteLen, как это ни странно звучит - c обычными ASCII...
Я когда это чудов отладчике увидел, аж испугался
Т.ч. Есть ANSI в VB, есть !!!
|
||
|
Номер ответа: 21 Автор ответа: sneРазработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445 |
Web-сайт: Профиль | | #21 | Добавлено: 27.01.05 03:14 |
| второй раз - ANSI = ASCII, уже сплю на ходу, ниче не соображаю... | ||
|
Номер ответа: 22 Автор ответа: CyRax  Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #22 | Добавлено: 27.01.05 05:34 |
|
Т.ч. Есть ANSI в VB, есть С использованием API или есть VB-шные команды? |
||
|
Номер ответа: 23 Автор ответа: sneРазработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445 |
Web-сайт: Профиль | | #23 | Добавлено: 27.01.05 10:48 |
|
Попробуй в дебагере посмотри Строка, на каждый символ - 1 байт, заканчивается нулем, а VB ее распознает как строку
|
||
|
Номер ответа: 24 Автор ответа: SharpЛидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #24 | Добавлено: 30.01.05 07:47 |
| Господа, а кто за вас память очищать будет? Если бы у вас было COM-взаимодействие с SysAllocString, за вас бы это Garbage Collector бы сделал, а так у вас в памяти процесса остается никому не нужная копия строки. | ||
|
Номер ответа: 25 Автор ответа: sneРазработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445 |
Web-сайт: Профиль | | #25 | Добавлено: 30.01.05 12:12 |
|
по-моему этим занимается VB автоматически... Помнится при сабклассинге из модуля дабы изменить св-ва класса, надо было скопировать в переменную того же типа указатель на тот самый класс... В итоге изменяли его св-ва мы... А если в конце забыть восстановить нулевое значение в этой самой переменной, то программа вылетает после выхода из оконной процедуры... а все почему, да потому как по тому самому указателю VB грохнул наш класс
Вот и тут я думаю что VB опосля выхлода из функции благополучно очищает все свои локальные переменные... |
||
|
Номер ответа: 26 Автор ответа: crestaВопросов: 117 Ответов: 1538 |
Профиль | | #26 | Добавлено: 30.01.05 13:48 |
|
Sharp, я смотрел это. Т.е. в цикле из 1000 повторений делал строку 200000 байт. И в каждом проходе цикла возвращался в VB с этой строкой. Если бы строка не уничтожалась, то по завершению цикла 200 Мб висели бы в памяти, но их нет. И ещё момент: Если на VB-стороне со строкой, полученной из dll ничего не делать, то программа вылетит через некоторое количество вызовов ф-ции. Т.е. если так: SomeFuncInDll
Если же с ней что-либо делать, например MsgBox SomeFuncInDll() или Debug.Print SomeFuncInDll() или MyVar=SomeFuncInDll(), то проблем нет. Видимо при этом очищается эта строка. sne, у меня что-то похожее было, когда делал асм-контрол с загрузкой картинки .jpg или .gif через OLE. В masmlib есть процедура загрузки рисунка. В ней используется CreateStreamOnHGlobal, pGlobal, TRUE, ADDR pStream Параметр TRUE продполагает автоматическое уничтожение выделенной памяти. А в конце работы с памятью было invoke CoUninitialize invoke CoTaskMemFree, pGlobal т.е. при CoUninitialize pGlobal освобождался из-зи параметра TRUE, и тут же сразу ещё раз попытка освободить свободное через CoTaskMemFree, pGlobal. Программа, куда вставлялся контрол, работала, но при завершении она с грохотом падала. Пришлось удалить CoTaskMemFree. |
||
|
Номер ответа: 27 Автор ответа: SharpЛидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #27 | Добавлено: 30.01.05 16:09 |
| Я невнимательно прочитал код, оттого и родилось мое неправильное утверждение | ||
|
Номер ответа: 28 Автор ответа: LamerOnLineICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #28 | Добавлено: 31.01.05 08:34 |
|
Действительно извратно А делать MyStr=Space(75000) - двойная работа (соответственно двойная затрата времени). Первый раз забиваем пробелами, второй раз поверх пробелов забиваем полезную инфу. Плюс ещё существенный момент: а если неизвестно заранее, какова будет длина возвращаемой строки? Выделять 2 Гб пробелов? Чтобы наверняка хватило Опять же это время, время, время...
От двойной работы ты все равно не избавишься. Либо ты передаешь ссылку на уже созданный буффер, либо копируешь в новую строку по ссылке ту, что была создана самой функцией. Вообще в АПИ все реализовано достаточно стандартно, не думаю что стоит далеко уходить от этого. Возвращаемое значение функции должно быть HRESULT. Соответственно, возвращаемая строка должна быть выходным параметром. Обычно делается так - передаются ссылки на буффер и на переменную, в которой указана его длина. В случае нехватики буфера в этой переменной возвращается длина требуемая. Время требуется ненамного больше, зато есть уверенность в результате. |
||
|
Номер ответа: 29 Автор ответа: sneРазработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445 |
Web-сайт: Профиль | | #29 | Добавлено: 31.01.05 11:51 |
| гы... а то что если не использовать строку, и она вылетает, это скорее всего из-за включенной оптимизации, т.е. VB возможно компилятор попросту вырезает ненужное, по его мнению... Хотя это всего и предположение... | ||
|
Номер ответа: 30 Автор ответа: crestaВопросов: 117 Ответов: 1538 |
Профиль | | #30 | Добавлено: 31.01.05 14:33 |
|
LamerOnLine
Не знаю, кто такой хрезульт, я возвращаю дворд
А два раза вызывать, первый раз - для определения длины - не есть гут. Представь, что процедура делает на банальное копирование, а что-то достаточно долгоиграющее например поиск файлов по маске на C:\, в результате чего получается строка неизвестной длины. Так что, два раза выполнять долгоиграющие действия? Типа: "Сейчас мы измеряли Ваш винт, а теперь будем ещё раз мерять и копировать названия" А уверенность в результате есть )
Да и не принуждает ведь никто возвращать BSTR. Не нравится - можно и два раза вызывать, делать буфер, разве я против
|
||