AlexManiac писал(а):я не отстаиваю чтение кусками(в текущем контексте)... прошу прощения, в моем первом предложении в этой ветке вот такой код:
- Код: Выделить всё
' Здесь действительно был код, читающий не побайтно, а одним махом
Циклов не видно
Читаем внимательно, балансируем между точностью и сомолюбием
Кроме твоего первого сообщения, было ещё и второе, почти полностью противоречещее первому. Обычно, когда два каких-то утверждения противоречат друг-другу, актуальным считается последнее. Например, если по новостям объявляют, что пострадало 6 человек, а потом говорят, что пострадавших нет, следует считать, что их-таки нет и первоначальная информация была ошибочной. По этой причине, утверждения твоего второго постинга override-ят утверждения первого. Поэтому на первое сообщения я даже не смотрю.
Второе, - наиболее актуальное сообщение -, содержит такую интересную мысль: ты говоришь, что ты согласен с
Antonariy. Ты говоришь это после того, как мы с Antonariy начали спорить.
Напомню тебе, что я посоветовал автору отказаться от побайтового чтения в пользу одноразового, мотивируя это тем, что побайтовому чтению не место в обучающем примере.
Antonariy выступил против этого совета, и назвал мой аргумент бессмысленным.
Итак, в споре:
Моя позиция - побайтовому чтению не место в примере.
Позиция
Antonariy - побайтовое чтение допустимо в примере.
Учитывая позицию Antonariy и то, что ты говоришь "
я вот тоже Antonariy поддерживаю" я могу сделать только один напрашивающийся вывод: твоя позция совпадает с позицией Antonariy - т.е ты также допускаешь побайтовое чтение в примере.
Поскольку ни я нигде не призывал использовать файл-маппинги в примере, ни Antonariy не говорил мне "Эй, Хакер, да ты не прав, предалагая в примере использовать файл-маппинги" -- я просто не могу считать, что говоря "
я вот тоже Antonariy поддерживаю" ты имел ввиду что-то отличное от "Даёшь побайтовое чтение!" (а чем-то отличным от этого могло бы быть наприме
"Согласен с Antonariy - долой файл-маппинги" -- но ведь нет, о них и не спорили).
Итак, разобрались, твоя позиция: побайтовое чтение допустимо в примере.
После того, как ты говоришь, что согласен с Antonariy, ты высказываешь некоторое противопоставление:
если человек пишет на VB, значит файл-маппинг изучать ему точно лишнее, иначе писал бы на чем-то, слоем ближе к API.
в котором опять упоминаются файл-маппинги.
Кажется очевидно, что ты пытаешься сказать "Нет, Хакер, ни к чему файл-маппинги; Antonariy прав", что по сути эквавалентно "Нет, Хакер, ни к чему файл-маппинги; побайтовое чтение допустимо в обучающем примере".
Т.е. ты противопоставляешь две крайности: оптимальный маппинг и невероятно тупое побайтовое чтение. Золотую середину (чтение с помощью Get, но за один раз) ты почему-то рассматривать не хочешь и не видишь.
Или видишь? И именно её имеешь в виду? Пожалуй нет, иначе фразы "
я вот тоже Antonariy поддерживаю" не было бы, ибо Antonariy против этой золотой середины, а я -- за. Была бы фраза "поддерживаю Хакера". Но т.к. её нет, вариант исключается.
После этого, на моё "
как AlexManiac, так и сам old761 почему то видят только байтовое чтение и файл-маппинг, и пытаются выбирать между этими двумя вариантами. " ты не имеешь права возражать.
Если судить идеалистически, то само наличие MSVBVMxx.DLL говорит о том, что Билли всю свою жизнь мечтал свое детище абстрагировать от системных вызовов, начиная с самых первых версий басика.
А по моему - совсем не говорит. То что там VM а не RTL, - так это только потому что людям жалко было из библы вырезать офигительный псевдокодовый движок. Да и смысла урезать фичастость не было.
Можно было конечно отделить RTL от VM, но тогда было бы две библиотеки. Сейчас библиотека одна, но встречаются, хмм... бараны, которые в своих "умных" статьях пишут, что программы на VB требуют для своей работы чуть-ли не десяток различных библиотек (записывая в этот список даже какие-то там ADO* и DAO* библы). И это при том, что библиотека всего одна. Что было бы, если бы их стало две - страшно представить.
Мне кажется, в .NET это ему удалось.
Мне, опять же, не кажется. Я согласен по этому поводу со
статьёй.
И сам VB проектировался как нечто платформ-независимое.
Откуда такое предположение?
Я сам сторонник "пошалить" в том месте (в той среде), которая для этого не предназначена.
Неправильное восприятие в том, что ты считаешь это шалостью. Вызов WinAPI-функции - это вещь (в системе Windows) чуть-ли не самая естественная, какая-только может быть.
Но согласитесь, изначально VB не предназначался для прямых вызовов API, не так ли ?
Что значит прямой вызов API? Чем он отличается от непрямого?
Или имеется в виду "прямое использование" и "неявное использование" (тогда так и надо писать, ибо вызов и использование - разные вещи).
ЗЫ:то же можно сказать про ассемблерные вставки в коде VB. конечно, сделать можно, но стоит ли на этом ставить ударение, типа "если вы такие ламеры что не можете сделать naked функцию в ВБ, значит учиться программить вообще не стоит" ??
Я скажу вот что. MS не сделала возможности делать inline-asm-вставки, не хотела делать возможность использовать API-функции, не сделала поддержку указателей, не сделала возможность делать на VB обычные DLL (а я эту возможность нагло
вернул, загубив весь замысел MS) потому что они придерживались концепции "безопасного программирования". Такого программирования, когда даже самый глупый программист, напиши он неимоверно кривой код, не сможет вызвать аварийную ситуацию, которую нельзя обработать. Имея асм, имея указатели - сделать что-то не то достаточно легко. Попробуйте написать на чистом VB что-то, что вызвало бы крах... И DLL -- так же: в случае не совпадения версий могут возникнуть совершенно не отлавливаемые и фатальные ошибки. Так что дело в принципе "безопасного программирования". И кросс-платформенность здесь не причём.
Новые веяния нам показывают, что наборы API меняются быстрее , чем кошки рожаются. Штампуются новые процессоры, каждый производитель в них [Хакер] :: Здесь был мат. Криптованый. Криптованый мат также запрещён правилами как хочет, от того кучи неясных сервис паков на базовые наборы API - как грибы после дождя.
Во-первых, у процессоров есть архитектура. И это не фиг собачий, и все процессоры с одинаковой архитектуры принципиально одинаковы. Как был, например, у x86-шных опкодов SIB, так он никуда и не делся.
Во-вторых, я не совсем понял, какая связь между выпуском процессоров и API. По моему, прямой связи нет. Вон, WinAPI уже сколько лет не меняется? Не
меняется, -- я не говорю что оно не расширяется, оно, разумеется, расширяется - добавляются новые и новые функции, но ведь уже имеющиеся кардинально не меняется. Как было 10 лет назад у CreateProcess() 10 параметров, так оно и сейчас есть, и ещё 10 лет, вероятно будет. Причём здесь изменения, которые происходят с процессорами?
Ну тогда, батенька, у Вас 