Симонов Денис,

смущает, но в данном случае влезть влезть внутрь компилятора и переписать строки
1) невозможно
2) если бы было возможно - было бы весьма трудно

а вот в твоём-моём случае не надо "убирать" блокировки, достаточно их "недобавлять"

Возвращаясь к строкам и BCD, в одном англоязычном FAQ отвечала на вечный вопрос о сравнении двух float на равенство.
И "правильный" ответ был - заменить "if f1 = f2" на "if FloatToStr(f1) = FloatToStr(f2)"

В принципе - код рабочий. Но какой-то он неправильный.

Вот твой совет ради копирования raw bytes создать и потом уничтожить dynamic array - с ним на мой вкус ровно та же проблема. Накладные расходы на порядки больше самого действия.

Симонов ДенисА от тебя лучших предложений пока не поступало

поступало

AriochВ общем, если там и делать Delphi helper, то возвращать он должен не TBytes (неформатированный дамп который может совпасть по длине и внутреннему содержимому с TBcd, а может и не совпасть), а сразу готовый TBcd. И не по указателю "из" SQLDA, а "на" SQLDA.

но, конечно, удобнее вопринимать реальность выборочно

Симонов ДенисAriochЁ! ещё и указатель надо взять не НА DA, а ИЗ DA. Т.е. DA придётся руками парсить.

не надо там ничего парсить. Сразу видно не разбирался.

AriochРазмер входного буфера никто не проверяет

Ну что ты написал - то и читаю

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

Это великолепно.
Т.е. две глобальных блокировки и две неизвестно какой сложности операции внутри pluggable heap manager - это нормально.
А одно сравнение integer с константой - это тормоза.

А давайте из Firebird'а все bugcheck'и уберём. Я-то рукожоп, что с меня взять, но вы-то не рукожопы, вы же чoткие пацаны.
Заодно и "дополнительных тормозов" меньше будет, сервер взлетит просто.

Ariochс проверкой на dialect 0 SQLDA
этого не нужно. Старый диалект только для совместимости со старыми компонентами. Он не используется уже лет 15. Разве что в недрах старого BDE. В новом API этого понятия нет вообще.

Мы тут как бы про старый API говорим, про введение в классический API integer-128 и какую адаптацию *существующих* библиотек доступа это повлечёт.

Arioch3. дёрганье хелпера, создающего "сырой" дамп в TBytes - ARC-структуре, т.е. запускающего две глобальные блокировки потоков процессора, как минимум две.

сразу видно что ты не пытался разобраться. Нет там никаких блокировок. Хелпер надо получить ровно один раз, а потом пользоваться им. В нём нет глобального состояния.[/quote]

Сразу видно, что ты не знаешь, что такое TBytes, хотя и заговорил про string, казалось бы в тему заговорил, но... Я удивлён.

Симонов ДенисВ последних версиях Delphi строки полученные из FB приходится перекодировать почти всегда (если только не AnsiString), ибо они в UTF-16, который никогда из FB не возвращается.

ты серьёзно не понимаешь, что перекодирование потока байтов из одного формата в другой не приводит к глобальной блокировке всех потоков одного, а возможно и всех процессов (префикс LOCK в x86)?

при этом как правило перекодируются строки длиннее, чем 16 байтов. Т.е. даже если приравнять остановку всех потоков к неблокирующей работе внутри одного процесса, то и в этом случае накладные расходы на строки вызываются много реже, чем для int128/bcd

> Не нравится иди на c++

А голову отрубать для удаления зуба - это принципиальная позиция Firebird Project ?

....не читатель, но писатель. Я ведь написал, как бы я это делал на Delphi.

Симонов Дениспосмотри как устроен TEncoding для перекодировки строк

Никогда не считал TEncoding образцом хорошего кода. Это просто тупой копипаст из C# не включая голову. Причём настолько не включая, что элементарно можно получить use after free и dangling pointer.
Потому что "цельнотянутое" API разрабатывалось для GC-языка.


Симонов ДенисAriochВ общем, если там и делать Delphi helper , то возвращать он должен не TBytes

с чего бы " интерфейсам" C++ который совершенно не привязан к Embercadro такое возвращать. Если хочешь пиши сам, да там как раз есть возможность хелперы классам писать. Это уже хелперы в терминах Delphi

И снова подмена предмета спора.
Ты начал разговор про какой-то неофигенно удобный Delphi хелпер, ради которого стоит отказаться от классического API и существующих библиотек, а теперь переключился на какой-то "непривязанный к Эмбаркадеро" новый Delphi-интерфейс.

AriochТ.е. две глобальных блокировки и две неизвестно какой сложности операции внутри pluggable heap manager - это нормально.
А одно сравнение integer с константой - это тормоза.

да откуда ты их взял? Пальцем покажи.

показывал уже, снова показываю - TBytes

Там для получения хелпера нет ни одного интерфейса с подсчётом ссылок, да и не забывай про паттерн синглетон, не надо 100500 раз один и тот же хелпер получать.

Я ж говорю, ты не знаешь что такое TBytes - но радостно его советуешь вместо memcpy как "правильное" решение. Ну как те ребята со сравнением float'ов.

кто мешает проверять допустимость длины буфера на клиенте?
А что, посоветованная тобой BcdFromBytes на сервере выполняется???
А мужики-то не знают.... (c)

Так-то я тебе и в SQLDA могу по указателю хрень воткнуть для любого типа
Можешь. Но там нет иллюзии безопасности. Там идёт работа с низкоуровневыми структурами данных.
А BcdFromBytes эту иллюзию создает. Принимая на вход ARC-завёрнутый буфер данных произвольной структуры и размера. И ожидая от кого-то создания этого буфера (с межпоточными блокировами и вызовоми заранее неизвестного heap manager) недокументированного размера и заполнения его в недокументированном формате. И потом убивания буфера (с межпоточными.....).

Фактически единственное относительно безопасное (на уровне source level compatibility с другими версиями Delphi или имитирующими Delphi сторонними языками) этой функции - только и исключительно использование в паре с BcdToBytes и никак кроме.

AriochМы тут как бы про старый API говорим,

ты не о том. Я тебе говорю что даже старый API завязанный на SQLDA уже как 100 лет не использует понятие диалект SQLDA. Параметр есть, пишут туда что-то отличное от 0. Оно с 0 реально используется только в совсем древних компонентах, куда всё равно новые типы никто портировать не будет.

А должно быть, кстати, не "отличное от нуля", а +1, поскольку это версия DA, предназначенная для дальнейшего расширения, и изначально означавшее то же самое, что SQL dialect....

Пока этот диалект DA задокументирован - библиотеки должны ожидать его прихода от сервера, хотя бы в размере "проверить и выдать ошибку".

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

Симонов ДенисТам и без того накладных расходов вагон и маленькая тележка

а поэтому давайте на ровном месте, без какой-либо пользы, сделаем ЕЩЁ БОЛЬШЕ накладных расходов

пц! пц! пц! (с)

Мимопроходящий2. "интерфейсное АПИ" разрабатывалось тоже без оглядки на Delphi

Зато Delphi разрабатывался с оглядкой на классическое API 21986134