Ребята, работе проги это не мешает, но получаю такой варнинг:


[DCC Warning] Unit1.pas(118): W1057 Implicit string cast from 'ShortString' to 'string' 

Впринципе я знаю, что это, но вот как можно от этого избавиться?

1 минута в google.

Это сообщение отредактировал(а) Amphiluke - 6.5.2011, 19:56

http://www.transl-gunsmoker.ru/2009/09/pchars.html#d2009

Короткие строки оставлены для обратной совместимости пятнадцать лет назад. Иными словами, их нужно было перестать использовать ещё пятнадцать лет назад.

CodeMonkey, они попадаются в system.pas (правда переосмысленные в utf8)

Ни за что! Они так удобны для использования в записях.
P.S.
К тому же и сам Борланд до сих пор ими пользуется, имхо. Иначе откуда ограничение в редакторе IDE на количество букв в строке pas-файла  ?

у меня для тебя плохие новости

Добавлено через 1 минуту и 44 секунды
в этом коротком литерале могут быть unicode-символы

Это какие?
"в этом коротком литерале могут быть unicode-символы" - эти что ли?

Оставляю за строкой неправильное упоминание термина литерал. 

Что IDE Delphi уже умеет в своём редакторе вставлять в текст исходника unicode-символ? Или она научилась понимать такой символ в строке pas-файла. Ты уж уточни, пожалуйста. 

Бедные азиатские пользователи ваших программ...

...а также программисты других языков (которым придётся ручками писать функции обработки этих строк).



То-то и оно, что пользуется он ими только по соображениям совместимости. И, как заметил bems, часто это не чистый ShortString. Они туда пихают UTF-8, чтобы компенсировать ограничения ShortString - откуда и лезет целый ворох проблем.

Я бы предпочёл, чтобы они это выкинули на помойку (раз отладить до сих пор не могут) и сделали бы как надо.



Unicode в редакторе и .pas файлах поддерживается начиная с D2005. Unicode-идентификаторы - с D2009.

Ну увы им, этим азиатским пользователям. Так я и не рассчитываю на их рынок.


А вот это для меня новость.

Я бы тоже много чего предпочёл изменить в своих ранних, но до сих пор поддерживаемых проектах. Но "где деньги, Зин"?

Ребята, вкратце

Для чего мне это нужно?

 

Это будет писаться в файл. Вот так:



Если не будет ограничения длины, не видать нам записи в файл...

Это сообщение отредактировал(а) PsiMagistr - 8.5.2011, 08:33

нет, про фирму борланд 

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

да, конечно

Разумеется.
С разморозкой Вас 

Добавлено через 3 минуты и 50 секунд
PsiMagistr, с ограничением по длине это уже ShortString а он единственный строковой тип, который не указатель. А писать указатель в файл не очень хорошая идея. Можно конечно и нормальные строки писать в файл, но там нужно чуточку больше телодвижений (которые впрочем можно возложить на rtl/vcl)

bems,  Развивайте мысль! .

Возложите, плиз. У меня не строки. В том то и дело. Записи у меня, со строковыми вкраплениями. Их и надо писать в файл. Если вам удастся обойти ShortString без лишних телодвижений  буду благода.

PsiMagistr, не, просто записать весь рекор одним махом не выйдет. а так вообще вот статейка
http://www.rsdn.ru/article/delphi/serialization.xml

Вообще забавная задача...

ЗАДАЧА:

 Записать в файл некоторый рекорд со строковыми вкраплениями произвольной длины. Ясно, что никакой шортстринг не прокатэ )))

Нужен чистый Стринг.

Поднимать для этого дела серилизацию объектов? Круто.

И что будем делать, Штирлиц?

Это сообщение отредактировал(а) PsiMagistr - 8.5.2011, 08:45

пиши каждое строковое поле отдельно. Для каждой строки пиши сначала её длину, а потом собственно символьные данные.

А чего, собственно, её поднимать? Она и так есть. По умолчанию.

Достаточно

заменить на:


И всё. И мы можем сохранять/загружать такой объект одной строчкой.

Ежели это всё равно кажется чем-то неудобным, то: http://www.delphikingdom.ru/asp/viewitem.a...talogid=1206#06

Немного разобрался. Наследовал, правда не от TPersistent, а от TComponent

и тогда


 FileStream.WriteComponent(объект)

Но записей можно хоть целую кучу в одном файле хранить и далее смещая файловый курсор-указатель (Seek) на длину (SizeOf(Record)

записи, находить нужную.

А как с объектами быть? Если мне их надо в одной пачке хранить. 

У меня по файлу с пачками записей образуется динам. массив записей. В нем столько ячеек, сколько записей в файле. Они туда все считываются. Но количество записей я рассчитать могу (Общая длинаФайла, деленная на длину 1 записи)

А с пачкой объектных данных как быть?

Заранее спасибо.

Это сообщение отредактировал(а) PsiMagistr - 8.5.2011, 18:38

Отвечать на форуме считаю неправильным решением. Отвечать в личке?

northener, пиши тут

Ну так и быть - пишу тут.
Вот вы произнесли/сказали - "короткий литерал" в сообщении от 7.5.2011, 13:54.
А что значит этот термин "короткий литерал"? Я такого термина не знаю. 

Есть несколько подходов. Самый грамотный - набор объектов должен загружать/сохранять объект контейнер.

Совсем простой вариант - так же, как и с "пачками записей".

Пишем объекты друг за другом в один поток. При чтении - читаем, пока не конец потока.

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

Давайте забудем об объектах. Автору объекты как таковые  не нужны. Так он считает и я с ним согласен.
Ведь он что хочет - записывать записи в файл и потом считывать их из файла.

Сначала ты говорил что я неправильно употребил термин литерал, а теперь говоришь что я говорю о несуществующем термине "короткий литерал"
Я говорил что 255 символов это ограничение на длину строкового литерала в дельфи (собственно поэтому я и назвал их короткими), а не на длину строки, как говорил ты.

Хм. Давай всё же перейдём в личку. И там спокойно, со временем,  разберёмся что, кто и когда говорил. Ибо я никогда не говорил ту ересь, которую ты мне приписываешь.

Говорил.
Вот тут ты говоришь что речь идет именно о термине "литерал"
А тут ты говоришь об ограничении длины строки пас-файла в 255 символов, хотя такого ограничения нет (там кажется 1024 или что-то такое), а ограничение в 255 именно что на длину строкового литерала
Не нужно. Есть предложение просто закрыть эту тему

Кстати ребята,

Вот создал я объект на основе другого объекта.

Добавил новые поля. Забаррикадировал поля свойствами.

Нужно ли мне переписывать деструктор?

Ведь если я воспользуюсь стандартным (присущим объекту родителю) то новые поля не будут уничтожены. Ведь старый деструктор ничего не знает о добавленных полях.

И

Если я должен переработать деструктор, что я туда должен записать? Как уничтожить поля?

Тяжела ты шапка программиста.



Имеется массив Mass, содержащий объекты с разными данными, но все естественно одинакового класса. 

Пытаюсь записать массив в файл.




Имею файл. В файле (хвала Рандому столько объектов сколько ячеек в массиве. И О УЖАС - во всех объектах одинаковые данные!)

Вот этот файл. Отчетливо видно два экземпляра. А вот данные одни и те же...

object Persones
  Name = 'Olya'
  Sirname = 'fdfd'
  Family = 'fdf'
end
object Persones
  Name = 'Olya'
  Sirname = 'fdfd'
  Family = 'fdf'
end

Нечто похожее обсуждается здесь.

http://forum.delphiexpert.ru/index.php?topic=1550.0


Фишка в том, что у меня если надо один объект в файл засейвить, то он худо-бедно сериализуется. А если много в один и тот же файл (Массив объектов и цикл соответственно) - полный обломейшн.

Но не под каждый же объект свой файл заводить? Это ж сколько файлофф  будет?

Implicit string cast from 'ShortString' to 'string' 
 читайте как
Implicit string cast from 'AnsiString' to 'string'
  с вытекающими отсюда последствиями

так как ShortString как был массив из AnsiChar так и остался.

Neobrat, я понял. спс.


Чумная вещь эта сериализация. С массивами объектов происходит жестяная штука. Сохраняется первый элемент массива и хоть кол теши.

Причем в файле имею 

Кучу записей.  И все заполнены первым элементом. Хотя массив содержит разные данные (тестировано).


Это сообщение отредактировал(а) PsiMagistr - 10.5.2011, 14:10

Зачем? не проще..


код

работает. 
Ищите ошибки в своем коде.
Зачем Вы приминаете сериализацию не совсем ясно. 

Это сообщение отредактировал(а) Neobrat - 10.5.2011, 14:46

Neobrat, WriteComponent из той же оперы

Надо данные объекта сохранить. Но объекты в массиве. В динамическом массиве. И считываться должны в массив.

Это сообщение отредактировал(а) PsiMagistr - 10.5.2011, 14:50

На пальцах: сериализация в Delphi осуществляется на базе TPersistent, TComponent и TCollection.

TPersistent - это базовый класс, который можно сериализировать. Единственная проблема с ним в том, что по умолчанию его сериализирует TComponent. Сам TPersistent себя сериализировать не может. Это, впрочем, можно легко исправить.

Поэтому, главный сериализируемый класс в варианте по умолчанию - TComponent.

Далее, наборы из объектов сериализируются как составная часть объекта-контейнера. Таковыми (опять же, по умолчанию) в Delphi выступают TComponent и TCollection.

Соответственно, для того, чтобы сериализовать массив из 3-х TComponent, их надо добавить в четвёртый TComponent, который будет контейнером, и сериализовать уже его. Обо всём остальном позаботится TComponent.

Либо же, мы можем использовать TCollection и добавить 3 объекта в неё. И она нам всё засериализует.

Это грубо, но наглядно.

К сожалению, на руках у меня демки с TComponent и TCollection нет, а разбираться в вашем коде - нет времени, но вот здесь можно посмотреть пример сериализации одного объекта TPersistent и набора из трёх объектов TPersistent. Думаю, что это ещё лучше, чем TComponent и TCollection.

Эта демка сохраняет и загружает один объект и коллекцию в бинарном и текстовом виде.

Вот пример сохранения одного объекта в текстовом виде:


Вот пример сохранения коллекции в текстовом виде:


Это сообщение отредактировал(а) CodeMonkey - 10.5.2011, 15:02

Neobrat,  и какая разница:



Добавлено через 3 минуты и 29 секунд
CodeMonkey, весьма благоДарен. Т.е. как я понимаю, засерилизовыать массив без применения  TCollection или объекта-контейнера не получится?

"Зачем Вы приминаете сериализацию не совсем ясно. "

Возможно не совсем правильно выразился.

Какие предпосылки вынуждают использовать сериализацию?


"Надо данные объекта сохранить. Но объекты в массиве. В динамическом массиве. И считываться должны в массив."

Смотря что за объекты, что за данные и для каких целей.
Лично мой взгляд, 
  если нужны просто данные, то использовать рекорды.
  если используются объекты VCL, то встроенную сериализацию.
  если собственные объекты, то 
   а) пишется своя реализация сериализации, а по русски говоря дописывается две функции LoadFile SaveFile, а так же объект "загрузчик" которые следит за целостностью файла и т.д. и т.п.
   б) используется XML

у всех есть свои плюсы и минусы, которые я не вижу смысла обсуждать, каждый решает сам.
в вашей же задачи я не вижу смысла использовать встроенную сериализацию, так как из обычной записи(читай набора байт) создаете VCL-ый объект.

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

мм.. не в ту сторону смотрите. 
чуток оптимизировал ваш код просто.

Neobrat, 

Вкратце

Для чего это нужно:

Записываются характеристики игрового персонажа.

Персонаж скорее всего будет объектом. Так логичнее.


Отсюда и сериализация


И в чем оптимизация между


FileStream.WriteComponent

и 

MemoryStream.WriteComponent 

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

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

лично я скорее всего сделал бы "Загрузчик" и добавил две функции к персанажу LoadFile SaveFile
либо стал бы использовать xml

Это сообщение отредактировал(а) Neobrat - 10.5.2011, 15:39

ObjectBinaryToText, оно вам надо? Желательно. Чтобы можно было редактировать в обычном блокноте.

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

Нет.

если есть, то попробуйте со стандартной сериализацией это провернуть.

лично я скорее всего сделал бы "Загрузчик" и добавил две функции к персанажу LoadFile SaveFile

Я тоже так хочу. 

либо стал бы использовать xml

что есть XML и с чем го кушать.

Добавлено @ 15:51
Почему отказался от рекордов:

При записи строковых переменных переменной длины (они у меня входят в рекорд) возникают траблы.  Добро пожаловать в ShortString

!  MetalFan

для цитирования есть кнопки "быстрая цитата" и тег [quоte][/quоte]

Это сообщение отредактировал(а) MetalFan - 13.5.2011, 18:52

по поводу xml, google в помощь. как раз там и сможете редактировать свойства и поддерживать версионость.

"Почему отказался от рекордов:

При записи строковых переменных переменной длины (они у меня входят в рекорд) возникают траблы.  Добро пожаловать в ShortString"

1. Признайтесь себе лично, реально ли у вас будут данные длиннее 255, из за чего вы не можете использовать ShortString;
2. Посмотрите куда смотрит указатель строки string и ShortString а так же посмотрите где лежит реальное начало строки, думаю поймете от куда грабли растут  почему рекорды с обычным string не сохраняться.

3. если уж вам все таки надо использовать string с переменой длиной, то так как вы все равно делаете в объекте то в SaveFile 
  пишите сначала длину строки а потом саму строку, ну и при загрузке наоборот сначала читаете длину, подготавливаете строку SetLength, или GetMem и т.п., и читаете саму строку

Признайтесь себе лично, реально ли у вас будут данные длиннее 255

Дело совсем-совсем не в этом. 

Если они будут меньше 255, в файле будут барахтаться пустышки

Это сообщение отредактировал(а) PsiMagistr - 10.5.2011, 16:29

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

bems,  именно так.

Добавлено через 5 минут и 15 секунд
если уж вам все таки надо использовать string с переменой длиной, то так как вы все равно делаете в объекте 

Если я делаю в объекте, то долой рекорд и да здравствует сериализация!

мда.. ну и задачу вы себе выбрали..
не хотим что бы были пустышки и не хотим делать ручками..

кроме как пожелать вам удачи не чем помочь не могу. )
посмотрите в сторону IniFile может поможет )))))

что нереального в задаче? сериализация потомков TPersistent нормально справляется

Я не говорю, что она плохо справляется. 

Но мне необходима инфа по сериализации отдельных объектов и коллекций.


Т.к. я в этом деле совсем зеленый.

а зачем тебе это?

Я не понял: а чего с моей демкой не так?

Всё, что там надо сделать - наследовать объект от TPersistent. Остальное сделает встроенный механизм сериализации.

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

ухожу из темы.

нет, совершенно целевое использование

CodeMonkey, 

Все так. 

Демку анализирую.

Будут вопросы.

Добавлено через 3 минуты и 17 секунд
CodeMonkey, 
Кстати, какой объект избрать контейнером? Форму? Она запишет много чего лишнего. 


Создавать спецобъект-пустышку без свойств и полей, только ради контейнера? 

Объект-контейнер, конечно же, не обязателен - это просто удобно, потому что он почти всё сделает сам. 

Что точно не нужно делать:
- Пытаться притянуть существующий объект, не связанный с вашими данными (форму).
- Относиться к контейнеру как к пустышке.

По последнему: ведь у вас в программе будет куча действий по управлению списоком, поиска по нему, ещё что-то. Вместо того, чтобы размазывать эти действия по программе - почему бы не внести их в класс-контейнер.

Пример: http://programmersforum.ru/showthread.php?...6354#post796354

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

Слово коллекция я употребляю как "набор объектов". Когда я имею в виду TCollection - я так и говорю: TCollection.

Во, наткнулся на текст: http://delphikingdom.ru/asp/viewitem.asp?catalogid=1426

CodeMonkey, 

Чтоб я в этом да что-то понимал. 

Сериализовал, сериализовал. Не выходит. А ежели объект наследовать от формы - выходит. Но от формы не годится, форма и свои свойства запишет. Интересно, как от Persistent записывать, если из методов только Write--ReadComponent, куда только от класса TComponent передать можно?

Чудеса в решете.

Ёлки-палки, я вам две демки на это дал, как это делать и использовать. Одну - свою (в том сообщении - ссылка на ZIP архив с демкой. Пропустили?), вторую - чужую.

Добавлено через 2 минуты и 22 секунды
В чём проблема-то возникает?

 



Это сообщение отредактировал(а) PsiMagistr - 11.5.2011, 15:14

Items 
это свойство Items объекта TTestObjectCollection. TTestObjectCollection - это контейнер из TTestObject. 

Items = 
"свойство равно"

Items = <>
"свойство равно пустому набору объектов"

Items = < объекты >
"свойство равно набору объектов"

Что тут необычного? Вот, вполне стандартный пример:


Набор объектов - это коллекция. Используется для сохранения набора объеков, которые не являются компонентами.

Добавлено через 3 минуты и 50 секунд
Имеется в виду, что когда у тебя в контейнере - компоненты, то они сохраняются так:

Но этот синтаксис не может быть использован для сохранения не компонентов - потому что у них нет Name. Поэтому используется другой синтаксис.

CodeMonkey, 

У Вас ангельское терпение. Спасибо.

Я первый раз с таким синтаксисом встретился.  стало быть

<> между  тегами набор объектов?


Сижу в демке, но 90 процентов кода не понимаю.

Я не просто так это делаю, а с корыстной целью 

По итогам я собираюсь написать очередную статью, где рассказать про сохранение/загрузку данных в файлы и потоки. И ответить на возникающие вопросы.




Да. Каждый элемент заключён в item/end.



Тот код, что в .pas модулях - понимать не надо. Это служебный код, который надо взять и использовать. 

Сама демка - это код в .dpr. Вот его надо разбирать.

Смотрите, как я уже говорил выше, TPersistent сам себя сохранять не умеет. Это можно легко добавить. Так сделано в http://delphikingdom.ru/asp/viewitem.asp?catalogid=1426 Там создаётся наследник TPersistent, который получает возможность сериализовать и десериализовать сам себя. Как видите, там всего пара строчек.

Вот, если вы наследуетесь от TBaseObject из той статьи, то автоматом получаете SaveToStream и LoadFromStream.

Но. Если вам нужно сериализовывать TPersistent (а не наследника) и вам нужно больше контроля, то можно действовать сложнее - как сделал я в своей демке.

Я не думаю, что есть смысл разбирать мой код. Вся его суть сводится к тем же нескольким строчкам из http://delphikingdom.ru/asp/viewitem.asp?catalogid=1426 Всё остальное - это внешний обвес, позволяющий делать дополнительные плюшки.

А вам из этого кода нужно вынести только одно: _WritePersistent сохраняет объект в поток, _ReadPersistent - загружает. Остальное - в .dpr.

CodeMonkey, 

Ящик пива с меня. Холодного. 

Я кончено рискую ВАс замучить, но


object CategoryPanel1: TCategoryPanel

Вот например, никогда бы не подумал, что можно и так написать.

Всегда считал, что все создается через классы.




Дело в том, что толковых книг по концепции ООП вообще практически нет. А вопросов у меня куча мала...

Это сообщение отредактировал(а) PsiMagistr - 11.5.2011, 17:29

Эээээ....  а вы отличаете .dfm и .pas файлы?

Вот у вас написано:



Вы что думаете это такое? Это - определение класса. Указана ли здесь информация о состоянии класса (т.е. "кнопка Button1 расположена по центру окна, которое имеет размеры 800x600")? Нет. Эта информация хранится отдельно - в .dfm файле. И загружается оттуда LoadFromStream (в моём примере: аналог - _ReadPersistent).

Вот в .dfm и написано:

Это - не Паскаль. Это - не код. Это - не определение класса. Это - сохранённое состояние объекта в текстовой форме. Т.е. просто данные.

Да, сохранённые данные, несомненно, связаны с определением класса. Но это - разные вещи.

Я понял.

В общем все реальные данные о состоянии вынесены в отдельный файл. 

Уфф. Продолжаю разбираться.

Это сообщение отредактировал(а) PsiMagistr - 11.5.2011, 18:11

CodeMonkey, 

РАЗБИРАЮСЬ. 

С Б-ей и Вашей помощью.


 UnitDefaultPersFiler in '..\UnitDefaultPersFiler.pas',
  UnitPersistent in '..\UnitPersistent.pas';

Какие-то особые модули, идущие в комплекте?



 _WritePersistent(FS, T, TDefaultTextWriter);

Вопрос. Что означает символ подчеркивания в начале строки?

Передаваемые параметры.

ПРавильно ли я понимаю:

1) FS - файловый поток Указатель-объект, класса TFileStream

2) T - сам записываемый объект.

3) TDefaultTextWriter - хотелось бы уточнить что это? На параметр не похоже. Указание особого режима?





Это сообщение отредактировал(а) PsiMagistr - 11.5.2011, 18:34

Почему везде употребляется служебное слово const? И что оно означает в данном конкретном случае. Если это передаваемый параметр, он ведь может изменяться? Т.е. ему нельзя быть const?

Разве недостаточно constructor Create(AStr: String; AInt: Integer);

Или const в данном случае означают те значения, которые будут переданы в поля, если конструктор вызван без параметров?

Object = TClass.Create; //Полям подставляются значения-константы. В нашем случае ' ' и 0

Вместо

Object  = TClass.Create(значение, значение); //Поля принимают введенные значения



Это сообщение отредактировал(а) PsiMagistr - 11.5.2011, 18:55

Это PersistentDemo.zip\UnitDefaultPersFiler.pas и PersistentDemo.zip\UnitPersistent.pas. Лежат в каталоге выше от PersistentDemo.zip\Demo\ProjectDemo.dpr

В эти модули вынесен служебный код. Там находится реализация _WritePersistent и _ReadPersistent



Ничего. Мне так захотелось. 



Прототип функции записан в UnitPersistent.pas. Его можно увидеть, если зажать Ctrl и щёлкнуть левой кнопкой мыши по _WritePersistent.

Вот:




Это опциональный параметр. Указывает, какой сериализатор использовать при сохранении. По умолчанию сериализатор в Delphi гонит в двоичный формат TPF0.

Вы можете использовать другой сериализатор. Например, тот, который пишет в текстовой форме. Именно это и делает TDefaultTextWriter - пишет в стандартный текстовый формат Delphi. Так что вам не нужно вызывать ObjectBinaryToText.

Список доступных сериализаторов можно посмотреть в модуле UnitDefaultPersFiler.pas. Пока их всего 4: читалка/писалка в двоичный формат и читалка/писалка в текстовый формат.

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


Потому что это хороший стиль.



Constant Parameters



Достаточно, но плохо.



Нет.