Delphi и ObjFPC такие разные

Любые обсуждения, не нарушающие правил форума.

Модератор: Модераторы

Re: Delphi и ObjFPC такие разные

Сообщение скалогрыз » 03.11.2014 18:29:05

kazalex писал(а):s[Pos('с', s)] := 'С';

так пишут в школах!
в институтах пишут так:
Код: Выделить всё
i := Pos('с',s);
if i>0 then s[i]:='С';


а в реальной жизни пишут что-то вроде:
Код: Выделить всё
  s:=StringREaplce(s, 'с','C', []);

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

Добавлено спустя 4 минуты 18 секунд:
pda писал(а):Разумеется я в кусре. Однако, всё хорошо лишь до тех пор... Пока не приходится брать ещё компоненты, которые созданы на базе стандартных или классы, которые требуют параметром TStrings. И тогда получаешь опциональную переделку с весёлым мейнтейном чужого кода...

ахаха, именно с тех пор среди делфинистов любую задачу принято начинать с написания своей rtl :mrgreen:

pda писал(а):
скалогрыз писал(а):хотя как сильно придётся танцевать с бубном я не знаю

Да не особо. Он делает obj, которые потом линкуются с любыми другими obj на чём угодно. Fpc создаёт совместимые obj и может линковать gcc'шные. Вот статья на тему.

разница в том, что FPC не сможет сделать из .c объектные файлы, только из .pas
а GCC сможет сделать и из .c и из .pas.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Delphi и ObjFPC такие разные

Сообщение kazalex » 03.11.2014 18:57:43

Mikhail писал(а):Уж лучше последовательная обработка сразу.

Любителям пожёсче редко что мешает :)

Mikhail писал(а):Я вижу всего 8.

Я же написал куда нужно смотреть: Table 3-7. Well-Formed UTF-8 Byte Sequences

так пишут в школах!
в институтах пишут так

На пересдачу. Можно было догадаться, что по условию задачи наличие 'c' в строке гарантируется. :P

скалогрыз писал(а):s:=StringREaplce(s, 'с','C', [])

Это не важно. В общем случае для UTF-8 работы будет сделано значительно больше.
kazalex
постоялец
 
Сообщения: 296
Зарегистрирован: 01.06.2012 14:54:10

Re: Delphi и ObjFPC такие разные

Сообщение Mikhail » 03.11.2014 19:27:22

kazalex писал(а):Я же написал куда нужно смотреть: Table 3-7. Well-Formed UTF-8 Byte Sequences


Смотрел - все равно не вижу. :?
Mikhail
энтузиаст
 
Сообщения: 562
Зарегистрирован: 24.10.2013 16:06:47

Re: Delphi и ObjFPC такие разные

Сообщение kazalex » 03.11.2014 19:59:59

Mikhail писал(а):Смотрел - все равно не вижу.

Выделил на картинке
У вас нет необходимых прав для просмотра вложений в этом сообщении.
kazalex
постоялец
 
Сообщения: 296
Зарегистрирован: 01.06.2012 14:54:10

Re: Delphi и ObjFPC такие разные

Сообщение Mikhail » 03.11.2014 20:13:36

kazalex писал(а):Выделил на картинке

Ну и где тут 26 проверок? :P
Mikhail
энтузиаст
 
Сообщения: 562
Зарегистрирован: 24.10.2013 16:06:47

Re: Delphi и ObjFPC такие разные

Сообщение kazalex » 03.11.2014 20:26:00

Mikhail писал(а):Ну и где тут 26 проверок? :P

Мне возле каждой отмеченной ячейки еще и цифры написать?
kazalex
постоялец
 
Сообщения: 296
Зарегистрирован: 01.06.2012 14:54:10

Re: Delphi и ObjFPC такие разные

Сообщение pda » 03.11.2014 20:42:51

скалогрыз писал(а):ахаха, именно с тех пор среди делфинистов любую задачу принято начинать с написания своей rtl :mrgreen:

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

pda писал(а):разница в том, что FPC не сможет сделать из .c объектные файлы, только из .pas
а GCC сможет сделать и из .c и из .pas.

И? Стандартная утилита gcc лишь выбирает форнтенд по расширению и использует соответсвующий компилятор для каждого языка. В итоге у вас всё равно получается набор объектных файлов, которые линкуются вместе.

Добавлено спустя 1 минуту 39 секунд:
kazalex писал(а):Мне возле каждой отмеченной ячейки еще и цифры написать?

Это не значит, что они все выполняются для каждой кодовой точки. За раз не больше четырёх.
Аватара пользователя
pda
постоялец
 
Сообщения: 303
Зарегистрирован: 27.05.2005 19:59:53

Re: Delphi и ObjFPC такие разные

Сообщение kazalex » 03.11.2014 21:01:14

pda писал(а):Это не значит, что они все выполняются для каждой кодовой точки.

А я этого и не говорил.
kazalex
постоялец
 
Сообщения: 296
Зарегистрирован: 01.06.2012 14:54:10

Re: Delphi и ObjFPC такие разные

Сообщение скалогрыз » 04.11.2014 06:29:54

pda писал(а):Я как-то не вижу повода для смеха. Я объяснил, почему ваша идея использовать сторонние компоненты, вместо того, чтобы сделать нормальными штатные неправильная. Вам смешно. Ладно. Хотите палец покажу?.

на самом деле, всё зависит от реализации компонентов. Например тот же TStrings работает прекрасно, если заранее сказать, что в него должны записываться строки в UTF8 кодировке.
Смех в том, что даже после подъёма "штатных средств" до уровня "мы теперь поддерживаем юникод", народ всё так же продолжает писать свои RTL-ы.
Смех №2, что люди, которые в бытность свою пересели на собственные/сторонние библиотеки, так и продолжают их использовать

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

По-этой же причине FPC всё ещё на system-locale RTL (в той же ситуации что и Delphi 7 и ниже). И регулярно устраиваются споры разных объёмов, уровней и масте, о том, что нужно бы подтянуть RTL до делфийского (юникодного).


pda писал(а):И? Стандартная утилита gcc лишь выбирает форнтенд по расширению и использует соответсвующий компилятор для каждого языка. В итоге у вас всё равно получается набор объектных файлов, которые линкуются вместе..

так я это и говорю - сплав С + Pascal в одной программном средстве разработки выглядит именно так!

Кстати, у Ембаркадеры в этом смысле было/есть преймущество. Т.к. RTL библиотеку для Си и для Делфи, они во многих местах могли бы сделать общую. Но насколько я знаю, слить делфи и Си толком, им не удалось... но если и удалось, то всё-равно принцип изложенный выше.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Delphi и ObjFPC такие разные

Сообщение pda » 04.11.2014 19:12:28

скалогрыз писал(а):Например тот же TStrings работает прекрасно, если заранее сказать, что в него должны записываться строки в UTF8 кодировке.

Угу. Со всеми особенностями "бесплатной" поддержки utf-8. Например, пока его не начнут обрабатывать функции, не понимающие что такое суррогатные пары. Причём не обязательно внешние. Можно очень весело на встроенный QuoteChar наступить. Ситуация, конечно не типовая, но от этого не менее весёлая. Собственно давно известно, что относительно безопасно можно использовать utf-8 вместо однобайтных кодировок только в ситуациях, когда строки только складываются.

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

Она нормальная, там, где изначально с головой писали. Впрочем, рукожопость проблема общая. Помню, когда начался массовый переход на 64 бита, из щелей поползли "крутые" сишники и c++ники с вопросами типа "а что, правда нельзя указатель к int приводить? а мы не знали..."

скалогрыз писал(а):что люди, которые в бытность свою пересели на собственные/сторонние библиотеки, так и продолжают их использовать

Я не верю, что причина столь осознанная. По моим наблюдениям, причина написания чего-то своего является банальный NIH-синдром. Людям просто лень смотреть в документацию или спрашивать у гугла. Самым простым примером является то, что многие дублирующие unicode-функции были добавлены ещё до решения о переводе rtl на уникод. Например, в Delphi есть TWideStrings, есть WideFormat... Сколько о них знают?

скалогрыз писал(а):так я это и говорю - сплав С + Pascal в одной программном средстве разработки выглядит именно так!

Ну, объектники и сейчас ни что не мешает слинковать.

скалогрыз писал(а):Т.к. RTL библиотеку для Си и для Делфи, они во многих местах могли бы сделать общую.

Они и сделали. C++ Builder мог компилировать делфовые исходники. Но особенным спросом, кроме как для установки делфовых компонентов в билдер это не пользовалось. Кстати, если вы про такое слияние языков, то его нет. У каждого языка своя rtl. Что-то подобное только Microsoft в своём .NET'е сделали, но только потому, что изначально на это закладывались. C++ тянет сишную библиотеку, но лишь потому, что сам вырос из C. И до добра это не доводит. Классический пример - оператор new. Привышие к alloc сишники взяли моду проверять его результат на неравенство null, а может в старых реализациях оно так и было, во всяком случае MSVC6 возвращает 0 при нехватке памяти. Но в стандарт вошло бросание исключения, которое почти никто не проверяет, потому что тупо копируют код у старших товарищей. (Это, кстати, и к вопросу о несовместимых изменениях в языке. :) )
Аватара пользователя
pda
постоялец
 
Сообщения: 303
Зарегистрирован: 27.05.2005 19:59:53

Re: Delphi и ObjFPC такие разные

Сообщение скалогрыз » 04.11.2014 20:29:53

pda писал(а):Угу. Со всеми особенностями "бесплатной" поддержки utf-8. Например, пока его не начнут обрабатывать функции, не понимающие что такое суррогатные пары.

Суррогатные пары есть в Utf-16, Utf-8 сам по себе весь unicode кодирует.

pda писал(а):Собственно давно известно, что относительно безопасно можно использовать utf-8 вместо однобайтных кодировок только в ситуациях, когда строки только складываются.

я выше писал, вместо того чтобы пытатся заменять "конкретный" символ, нужно менять "подстроку" (utf-8 символ на Х-байт - частный случай подстроки).
Такое обращение, работает и для замены подстроки и для удаления - надёжно и безопасно.
Сейчас придёт kazalex, и скажет, что "работы с utf8 больше", а я буду вынужден напомнить ему про utf-16 и упомянутые выше суррогатные пары.

Utf8 очень хорош, для "технических" заданий. Большинство "технических" текстов используют символы в пределах первых 127 байт - английский текст. А значит любимое сравнение 1 символ = 1 байт можно легко и смело применять.... ах да, новые вариации языков позволяют идентификаторы называть произвольным языком. Но это тоже достаточно просто решается, если учесть что в любой символ в районе #128..#255 - является корректным для имени идентификатора.

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

Код: Выделить всё
var
  ☃  : integer;
begin
  for ☃ :=1 to N do
    writeln( ☃  );


pda писал(а):Я не верю, что причина столь осознанная. По моим наблюдениям, причина написания чего-то своего является банальный NIH-синдром. Людям просто лень смотреть в документацию или спрашивать у гугла. Самым простым примером является то, что многие дублирующие unicode-функции были добавлены ещё до решения о переводе rtl на уникод. Например, в Delphi есть TWideStrings, есть WideFormat... Сколько о них знают?

Не без NIH :)
но скажем, TWideStrings в D7 нет, а программу с мультиязыком нужно писать, вот и делали свои решения для всего.
А раз они были написаны давно, проверены и работают, зачем переписываться на новый RTL?.. который не факт, что ещё останется без изменений.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Delphi и ObjFPC такие разные

Сообщение pda » 04.11.2014 20:45:43

скалогрыз писал(а):я выше писал, вместо того чтобы пытатся заменять "конкретный" символ, нужно менять "подстроку" (utf-8 символ на Х-байт - частный случай подстроки).

Заменяем все латинские "A" на "B" в строке, где есть ангстрем в декомпозированном варианте. :)

скалогрыз писал(а):А раз они были написаны давно, проверены и работают, зачем переписываться на новый RTL?.. который не факт, что ещё останется без изменений.

Для замороженного кода с делфой бесплатно раздают 2007.
Аватара пользователя
pda
постоялец
 
Сообщения: 303
Зарегистрирован: 27.05.2005 19:59:53

Re: Delphi и ObjFPC такие разные

Сообщение скалогрыз » 04.11.2014 21:07:11

pda писал(а):Заменяем все латинские "A" на "B" в строке, где есть ангстрем в декомпозированном варианте. :)


Есть мнение, что данный пример неудачный, а ты пытаешься про диакретические знаки рассказать?
Код: Выделить всё
uses
  SysUtils;

const
  A=#$41;
  AO=#$C3#$85; // U+00C5
  Angstrom = #$E2#$84#$AB#$20; // U+212B
  BOM = #$EF#$BB#$BF;
var
  f : text;
  src : string;
begin
  src := A+AO+Angstrom;
  assign(f, 'init.txt'); rewrite(f); write(f,BOM); write(f,src); close(f);
  src := StringReplace(src, 'A','B', [rfReplaceAll]);
  assign(f, 'final.txt'); rewrite(f); write(f,BOM); write(f,src); close(f);
end.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Delphi и ObjFPC такие разные

Сообщение pda » 04.11.2014 23:39:57

Попробуйте вместо:
Код: Выделить всё
AO=#$C3#$85; // U+00C5


вставить:
Код: Выделить всё
AO=#$CC#$8A; // U+030A 'COMBINING RING ABOVE'


Что теперь получается?
Аватара пользователя
pda
постоялец
 
Сообщения: 303
Зарегистрирован: 27.05.2005 19:59:53

Re: Delphi и ObjFPC такие разные

Сообщение kazalex » 05.11.2014 00:11:52

скалогрыз писал(а):Сейчас придёт kazalex, и скажет, что "работы с utf8 больше", а я буду вынужден напомнить ему про utf-16 и упомянутые выше суррогатные пары.

С суророгатными парами мало кому вообще улыбнется встретиться, тогда как кодирование в UTF-8 суровая реальность за рамками ASCII :)
kazalex
постоялец
 
Сообщения: 296
Зарегистрирован: 01.06.2012 14:54:10

Пред.След.

Вернуться в Потрепаться

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 13

Рейтинг@Mail.ru