tag:blogger.com,1999:blog-1702873441071265539.post2632220399538197041..comments2011-12-28T10:17:42.740+04:00Александр Алексеевhttps://profiles.google.com/113168002104297556003noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-1702873441071265539.post-172141017628684132011-12-28T10:17:42.740+04:002011-12-28T10:17:42.740+04:00Ну, как бы плюсы и минусы я писал в сравнении с другими методами работы с файлами. Такая логика.Александр Алексеевhttp://www.blogger.com/profile/15611696588191431330noreply@blogger.comtag:blogger.com,1999:blog-1702873441071265539.post-32949390445525283802011-12-28T10:16:37.969+04:002011-12-28T10:16:37.969+04:00<i>Попробуй открыть файл с нужным доступом. У тебя не получится сделать это потокобезопасно, потому что FileMode - глобальная переменная</i><br />Ааа, ты имеешь в виду, для Паскалевских файлов? Я просто ни разу это не юзал. Тогда не спорю, это в самом деле не потокобезопасно.Fr0sTnoreply@blogger.comtag:blogger.com,1999:blog-1702873441071265539.post-45463360022585297942011-12-27T20:48:57.264+04:002011-12-27T20:48:57.264+04:00<i> &gt;&gt;&gt; А где они меняются?</i><br /><br />Этот вопрос суть раскрывает. На красный свет тоже можно переходить. Только это не делает это правильным.<br /><br /><i> &gt;&gt;&gt; Хм, что-то не понял, при чем тут FileMode</i><br /><br />Ну как же. Попробуй открыть файл с нужным доступом. У тебя не получится сделать это потокобезопасно, потому что FileMode - глобальная переменная. <br /><br />А с потоками данных никакой проблемы нет. Поток данных, созданный во вторичном потоке, никак не связан (и не влияет) с потоком данных в главном потоке - если, конечно, ты сам их не свяжешь (например, натравив оба потока данных на один источник). Но это как бы уже ты сам себе злобный буратино, а сам по себе поток данных проблем не привносит. В отличие от FileMode.Александр Алексеевhttp://www.blogger.com/profile/15611696588191431330noreply@blogger.comtag:blogger.com,1999:blog-1702873441071265539.post-48337305926737987392011-12-27T18:23:30.309+04:002011-12-27T18:23:30.309+04:00<i>Мне кажется, ты неявно за меня немножко домыслил то, что я не говорил. Обрати внимание, что речь идёт про отправку и приём данных.</i><br />Возможно, да, а возможно, и нет. Да, приём и отправка данных - это как раз то, с чем я работаю. И мне как-то ни разу не хотелось юзать поток для хранения данных. Потому как для сетевого обмена, например, особенно если это - сплошной поток (какая ирония!), stream не подходит, а скорее нужна очередь. Да, функционала очереди можно добиться от стрима парой новых методов, но не суть. В принципе, я вообще не очень люблю, когда над указателями и блоками памяти навешивают свои типы. Взять, к примеру, TBytes, с которым плотно работает TEncoding. Понятно, что это слизано с .Нет, где другого средства нет. А вот в нативке, если у тебя уже есть буфер с данными, куда засунуть этот TBytes? Придется так или иначе копировать, а это затраты времени и памяти. Так же, к примеру, и с Format - иногда бывает, что нужно инжектить результат в имеющийся символьный буфер, ан фигу. Слава Небесам, что есть FormatBuf - а ведь его могло бы и не быть!<br /><i>То, что генерик тип не меняется на одной конкретной платформе ещё не означает, что он не меняется вообще.</i><br />А где они меняются? Ну, кроме 16-битной платформы (и то не уверен, а искать неохота).<br /><i>В общем-то да, но тогда придётся объяснять где взять этот тип на Delphi 7.</i><br />Ну что ж, кто хочет совместимости, тот должен быть готовым к куче дефайнов! Конечно, в качестве примера с этим можно и не заморачиваться, но вообще хорошо бы упомянуть, что (U)Int## как раз и предназначены для простого и наглядного объявления переменной фиксированного размера.<br /><i>Сравни это с переменной FileMode. Речь про это.</i><br />Хм, что-то не понял, при чем тут FileModeFr0sTnoreply@blogger.comtag:blogger.com,1999:blog-1702873441071265539.post-28869585979301898402011-12-27T16:33:55.217+04:002011-12-27T16:33:55.217+04:00<i> &gt;&gt;&gt; 3 - соглашусь (хотя такое и может понадобиться для ограничения типа), а вот 1, 2 - нет. Оперируя с буфером, буфер и передаёшь, необходимость мутить дополнительные объекты потоков - излишня и раздражает.</i><br /><br />Мне кажется, ты неявно за меня немножко домыслил то, что я не говорил. Обрати внимание, что речь идёт про отправку и приём данных.<br /><br />Разумеется, могут быть случаи, когда в контексте задачи имеет смысл только буфер памяти - в этом случае 1 и 2 более чем уместны и даже, более того, п3 не пригоден. <br /><br />Я же говорю как раз о ситуациях, когда данные могут быть где угодно, но человек всё равно пишет Pointer - и всё тут. В результате вместо того, чтобы просто передать поток, вызывающему придётся данные загрузить самому. <br /><br /><i> &gt;&gt;&gt; Integer и Cardinal не меняют своих размеров на х64, только указатели и Native(U)Int</i><br /><br />То, что генерик тип не меняется на одной конкретной платформе ещё не означает, что он не меняется вообще.<br /><br /><i> &gt;&gt;&gt; Но если уж нужна фиксация по размеру, то логичнее юзать UInt32.</i><br /><br />В общем-то да, но тогда придётся объяснять где взять этот тип на Delphi 7.<br /><br /><i> &gt;&gt;&gt; C чего бы это?</i><br /><br />Сравни это с переменной FileMode. Речь про это. Если угодно: &quot;нет никаких <b>специальных</b> проблем&quot;.Александр Алексеевhttp://www.blogger.com/profile/15611696588191431330noreply@blogger.comtag:blogger.com,1999:blog-1702873441071265539.post-53896070268023569052011-12-27T14:46:07.230+04:002011-12-27T14:46:07.230+04:00<i>Если вы в своей процедуре принимаете или отправляете какие-то данные - используйте TStream. Не используйте для этого нетипизированные параметры, указатели или конкретные экземпляры TStream. Т.е. вместо:<br />1 procedure A(AData: Pointer; ADataSize: Cardinal);<br />2 procedure B(const AData; ADataSize: Cardinal);<br />3 procedure C(AData: TFileStream);<br /><br />должно быть:<br />1 procedure A(AData: TStream);<br />2 procedure B(AData: TStream);<br />3 procedure C(AData: TStream);<br /></i><br /><br />3 - соглашусь (хотя такое и может понадобиться для ограничения типа), а вот 1, 2 - нет. Оперируя с буфером, буфер и передаёшь, необходимость мутить дополнительные объекты потоков - излишня и раздражает. Поэтому точно так же, как есть LoadFrom/WriteToFile, надо делать перегруженные методы для непосредственной работы с блоком данных.<br /><br /><i>Обратите внимание, что в качестве счётчика длины используется LongInt, а не Integer - по причинам, указанным выше для типизированных файлов: String, Extended, Integer и Cardinal могут менять свои размеры в зависимости от окружения - поэтому мы используем другие типы, которые гарантировано всегда имеют один и тот же размер.</i><br />Integer и Cardinal не меняют своих размеров на х64, только указатели и Native(U)Int. Но если уж нужна фиксация по размеру, то логичнее юзать UInt32.<br /><br /><i>Нет проблем с многопоточностью</i><br />C чего бы это? Отсутствие проблем может быть только для handlestream, и то только потому, что ОС заботится о синхронизации доступа. А всё остальное, тот же memorystream, абсолютно так же подвержен проблемам, как и любой буфер в куче.Fr0sTnoreply@blogger.comtag:blogger.com,1999:blog-1702873441071265539.post-26311818378191780482011-12-01T19:58:55.674+04:002011-12-01T19:58:55.674+04:00Офигеть, на Delphi пишу с момента ее выхода, и по прочтении статьи понял, что Delphi я не знаю...AlekVolsknoreply@blogger.comtag:blogger.com,1999:blog-1702873441071265539.post-10075091195395962212011-11-14T12:33:51.505+04:002011-11-14T12:33:51.505+04:00День добрый.<br />Интересная статья, да и сама тема серии.<br />Именно так и делаю. Для себя принял строгое правило: все данные которые выходят за границу программы или dll, обязательно дополнять версией! То есть сначала пишу версию, а потом все что нужно. В качестве версии замечательно подходит TGUID, и размер стандартный и неповторяемость почти 100%. Что еще хорошо, если какой либо интерфейс пишет данные, то он может подписаться своим GUIDом. При загрузке данных, сначала читаем GUID, если знаем такой, то читаем все остальное, не знаем, ругаемся на не поддерживаемый формат данных.<br />Всем удачи!nik0laynoreply@blogger.com