![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
KOL и D2009
SPeller © (2009-03-26 17:10:00)Кто-нить работал? А то я подключил сам kol, компилируется после небольшой доработки напильником, но такую тучу ворнингов выдет относительно строковых преобразований, что мама не горюй. Были пару
опасных, но не помню уже где - поправил. Есть и замечания/вопросы:
- Что за ерунда с KOLString/KOLChar? Половина функций работает с KOLChar, половина нет, только с AnsiString, в результате те, что только AnsiString, не могут корректно работать с родными дельфийскими юникодными строками.
- Для некоторых функций определены юникодные аналоги с префиксом W. Но не все. Это они просто никому небыли еще нужны, или есть тайный смысл?
- В чем смысл когда одни функции работают с KOLString и когда другие вместо этого обретают сестер с префиксом W? Почему небыло выбрано одной стратегии?
- Есть желание заменить WideString/WideChar на string и Char, на родные дельфийские типы, как рекомендуют авторы. Вводить еще один тип KOLWideString? А то неохота при нативной поддержке юникода мешать родной тип строк с ком-строками.
Вобщем, зарылся тут с этим, в голове каша, боюсь старый добрый KOL юзать :)
Vladimir Kladov (2009-04-01 16:00:00) [21]Игнорироваться символы могут, если их много. И в ранних Delphi была такая же фишка. Слишком короткий буфер на строку, остальное отбрасывается. Новые Delphi практически никогда не исправляют старые баги, только новых плодят.
SPeller (2009-04-01 13:38:00) [22]
> Там работы "вагон и большая телега"...надо очень много править
Ага. Я потихоньку для себя делаю )
> чтобы доступ был к обоим вариантам, а по директиве выбирался
> нужный (если то необходимо).
Я тоже пришел к такому выводу относительно функций управления строками (strlen, strcmp и т.п.). А вот функции вроде Trim и Int2Str - это стопудово только KOLString.
> D[u]fa (31.03.09 11:53) [27]
Я не смотрел, но так и подумал.
> При использовании D2009 директива UNICODE_CTRLS, установленная
> для проекта, !!!игнорируется!!! в KOL.PAS
У меня не игнорировалась. Но я у себя для д2009 прописал принудительную установку этой директивы.
MTsv DN (2009-04-01 09:55:00) [23]Кстати, вот еще что. В свое время, для TDirList.ScanDirectoryмной был предложен код проверки на unicode символы:
{$IFDEF UNICODE_CTRLS} //+MtsVN in 2.58 / 14Apr2007
IsUnicode := FindData.cFileName;
if (IsUnicode <> '.') and (IsUnicode <> '..') then
begin
if pos('?', IsUnicode) > 0 then
CopyMemory( @FindData.cFileName, @FindData.cAlternateFileName,
SizeOf(FindData.cAlternateFileName));
end;
{$ENDIF}
не знаю почему сразу это не сделал, но для себя ввел еще дополнительно одну директиву. Сейчас код такой:
{$IFDEF UNICODE_CTRLS} //+MtsVN in 2.58 / 14Apr2007
{$IFDEF FORCE_ALTERNATEFILENAME}
IsUnicode := FindData.cFileName;
if (IsUnicode <> '.') and (IsUnicode <> '..') then
begin
if pos('?', IsUnicode) > 0 then
CopyMemory( @FindData.cFileName, @FindData.cAlternateFileName,
SizeOf(FindData.cAlternateFileName));
end;
{$ENDIF}
{$ENDIF}
Чтобы пользователь сам мог выбирать с какими именами работать, благо оба варианта работают нормально...
MTsv DN (2009-04-01 09:49:00) [24]2 Speller
В общем, самый простой вариант решения проблемы (компилятор перестает ругаться) такой.
Сейчас:
s : ansistring;
...
s := Trim( Copy( s, j, MaxInt ) );
Ошибка:
[DCC Warning] KOL.pas(13942): W1057 Implicit string cast from 'AnsiString' to 'WideString'
[DCC Warning] KOL.pas(13942): W1058 Implicit string cast with potential data loss from 'WideString' to 'AnsiString'
Правка:
s := AnsiString(Trim( KOLString(Copy( s, j, MaxInt ) )));
Ошибок нет.
Кстати, заметил вот еще какую фишку...не знаю, может это только у меня в проекте. При использовании D2009 директива UNICODE_CTRLS, установленная для проекта, !!!игнорируется!!!в KOL.PAS. Первой строчкой пришлось дописать:
{$define UNICODE_CTRLS}
D[u]fa (2009-03-31 11:53:00) [25]SPeller, смотри KOL_unicode.inc и как он подключен:
{$DEFINE interface_part} {$I KOL_unicode.inc} {$UNDEF interface_part}
.....
{$DEFINE implementation_part} {$I KOL_unicode.inc} {$UNDEF implementation_part}
Vladimir Kladov, да я в курсе) причем со временем "эксплойт" получилось заточить под новые версии))
Я просто высказывал то "что хотелось бы", но это не инструкция к действию
MTsv DN (2009-03-31 10:05:00) [26]Все. Понял про что ты... В принципе, такие ворнинги должны были и других версиях быть. Просто не соответствие типов, типа Str2Extended получает AnsiString, а в функции используется CopyEnd c KOLString в параметре. При UNICODE_CTRLS, соответственно лажа. Несоответствие типов и возможность утери данных...
Там работы "вагон и большая телега"...надо очень много править. Возможно пересмотреть политику использования A и W функций, чтобы доступ был к обоим вариантам, а по директиве выбирался нужный (если то необходимо)...
SPeller (2009-03-31 02:29:00) [27]
> в КОЛе есть способ как в один инк засунуть и описание и
> реализацию
{$IFNDEF func_impl}
declaration
{$ELSE}
implementation
{$ENDIF}
?
SPeller (2009-03-31 02:28:00) [28]
> Я щас совершенно спокойно с UNICODE_CTRLS откомпилил свой
> проект
Я тожа откомпилил. Ты ворнинги посчитай, и посчитай места, где юникод в анси преобразуется. В таких местах текст, не соответствующий локали, превращается в вопросики. Кроме того, надо понимать, что при любом преобразовании компилятор, где может, вставляет соответствующие вызовы функций. А это не может играть в сторону снижения объема конечного бинарника и в сторону увеличения быстродействия.
MTsv DN (2009-03-30 18:38:00) [29]> Можно сказать, это - эксплоит в Delphi.
8) +1
Vladimir Kladov (2009-03-30 18:35:00) [30]И я бы внёс обратно, но вспоминаем ограничение на 64К строк. Дальше возникают проблемы с отладчиком в Delphi. Или речь об inc-ах в проекте MCK? Там тоже далеко не всё можно. Есть такие хитрые inc-файлы, которые изначально нужны для обмана Delphi IDE, чтобы он в дизайнере "думал", что имеет дело с классом VCL, и мог работать с формой. Если их засунуть в сам файл, Delphi скажет, что это не юнит с формой. Вообще, не знаю каким чудом удалось получить такой результат. Можно сказать, это - эксплоит в Delphi.
D[u]fa (2009-03-30 17:32:00) [31]SPeller, в КОЛе есть способ как в один инк засунуть и описание и реализацию.
Вообще считаю что нет смысла разбивать на файлы КОЛВин, колфайлс.... и т.д. И плодить инки тоже не стоит, я бы наоборот большую часть инков убрал бы и внёс в сам КОЛ.пас.
MTsv DN (2009-03-30 16:52:00) [32]2 SPeller
Слушай, а где у тебя косяки в 2009 вылазят? Я щас совершенно спокойно с UNICODE_CTRLS откомпилил свой проект...
SPeller (2009-03-30 02:48:00) [33]
> а разве нельзя так:
Можно, но не удобно прыгать по Ctrl+Up/Down с описания на реализацию. Кроме того, в один .inc не засунешь описание и реализацию, на два надо бить. Я так уже вычёсывал объявления функций, сначала в inc, потом в конец интерфейсной части. Чтобы в одном месте все были все функции. Получилось, но где-то посеял директиву компилятора и теперь на непонятной строке выскакивает Unterminated conditional directive :)
GMax (2009-03-30 01:18:00) [34]а разве нельзя так:
unit KOL;
{$I kolstrings.inc}
{$I kolthreads.inc}
[...]
end.
а для отдельных случаев
unit KOLStrings;
{$I kolstringsd.inc}
end.
в экзотических случаях даже может меньше получится, наверное :)
Vladimir Kladov (2009-03-28 22:11:00) [35]Плка всё и так хорошо. Есть отдельная версия для WinCE. Разве оно плохо, что она немного отличается? Другое дело, если туда что-то добавлено кардинально полезное, что могло бы пригодиться в Windows-версии. Предлагайте код, вставим.
Можно сделать аналогично параллельную версию для линукса. Я так начинал для GTK+, но некогда стало заканчивать. Да и не линуксоид я, максимум, что смогу проверить - что оно компилируется под windows и работает с версией GTK+forWindows.
Похоже, это и есть оптимальный путь. Хотя и требует дополнительных усилий по синхронизации.
А делить на версии: мне не очевидно, в чём преимущество дробления исходного файла на 6 частей. Если с точки зрения использования KOL, так гораздо проще один раз в uses иметь ссылку на KOL, чем отдельно на KOLwindows, KOLfiles, KOLregistry, KOLmain, KOLadd, KOLxyz и т.п. Если с точки зрения разработчика KOL, так гораздо проще и удобнее всё находить в одном файле, чем рыться по целой директории. Так что мне очевидней, что одним файлом удобнее.
SPeller (2009-03-28 19:45:00) [36]Тут нужно придумать хитрую штуку. Чтобы и на старых дельфях микроутилиты не выросли, и чтобы на новых небыло затруднений.
Есть один грубый путь, который есть всегда - послать всех лесом и сделать так, чтобы было правильно с идеологической точки зрения. Но, на сколько я помню историю KOL, такое исключено. Можно попытаться унифицировать функции rtl так, чтобы они работали везде так, как от них ожидают на каждой версии дельфей. Объекты с префиксами W - ладно, пусть придется переправить свои исходники. Но вот править вызовы обычных стандартных функций - это уже бред, имхо.
Тут появляется две строны, тянущие один канат в разные стороны: те, кто изначально ansi, но хотят работать с юникодом в отдельных местах, и те, кто изначально юникод, и хотят чтобы их данные нигде не потерялись. Первые хотят появления сестер с префиксом W, а другие хотят унификации в виде KOLString/KOLWideString и плясок от количества байт в символе. Вот тут мне и представляется основная проблема. Как и волков сытыми оставить, и овец сохранить.
MTsv DN (2009-03-28 11:48:00) [37]Кстати, Вы так и не ответили на более Глобальный Вопрос...
MTsv DN (2009-03-28 11:46:00) [38]Не слишком большое, максимум 5-6... Я уже говорил о том, что по моему мнению, надо вынести отдельно...
А преимущества, очевидны. Удобнее работать когда все систематизировано, и находится там где ожидаешь, а не все в одной куче...
Vladimir Kladov (2009-03-28 11:42:00) [39]Удобство программирования - это VCL/CLX. А на сколько модулей вы хотите разбить KOL.pas? Умножить 100 на это количество не забудьте. Притом, что я вобще не понимаю, каким образом удобство программирования связано с количеством модулей, на которые разбит модуль KOL.pas. Опишите преимущества, пожалуйста. В чём они заключаются?
MTsv DN (2009-03-28 11:38:00) [40]Я в общем-то, несколько ошарашен... Что Вы готовы пожертвовать удобством программирования за 100 байт... Ребилд ехе-шника, плюс сжатие UPX-LZMA компенсирует это на "раз-два-три"... Ну, ладно... Здесь я Вашу позицию понял...
Владимир, а можно все же услышать ответ на вопрос:
Какие у Вас планы по поводу будущего KOL'а?