Convert Double to LARGE_INTEGER

[sosed213]

Особенно с учётом того, что ты сторонник философии «какой код нашёл, такой и использую, пока не найду варианта получше».

По этим словам, приятно осознавать что "тебя запомнили", но здесь ты прав, пока я склонен использовать один из последних вариантов

[arthur2]

Единственный правильный в твоём случае код, это код, который пройдётся по строке и на основании этого сам заполнит поля LARGE_INTEGER-а. Без всяких там Val и CDec.

А чем именно мой код плох? В чем могут быть грабли? Я не могу представить ситуации, в которой результаты моего кода вдруг не совпадут с результатами правильного ручного заполнения полей LARGE_INTEGER-а

[Хакер]

Тем же, чем и вариант с Val. И Val и CDec с радостью съедят потенциально нежелательные и неверные варианты, и даже дадут потенциально неправильные результаты.

Не нужно быть беспечным. Не нужно перекладывать ответственность по обработки строчки и её конвертации в число с себя на библиотеку функций языка. Если бы там были были достаточно хорошие функции, принимающие много сведений о том, по каким правилам обрабатывать числа, то это был бы хороший вариант.

Это очень легко, это очень упрощает жизнь программисту, но это и очень портит программу и усложняет жизнь пользователю. В моих серьёзных программах (не поделках для себя) не используются функции Val и atoi.

И к тому же Decimal — нецелочисленный тип. Это автоматически означает, что он не может вместить в себя всё то множество чисел, которое может вместить в себя LARGE_INTEGER.

[arthur2]

Не нужно быть беспечным. Не нужно перекладывать ответственность по обработки строчки и её конвертации в число с себя на библиотеку функций языка. Если бы там были были достаточно хорошие функции, принимающие много сведений о том, по каким правилам обрабатывать числа, то это был бы хороший вариант.

Ну, можно сделать дополнительные проверки строки на корректность - типа, чтобы запятых не было. В общем, ты просто предлагаешь написать собственный вариант Val? но так, чтобы он учитывал все возможные некорректные значения?

И к тому же Decimal — нецелочисленный тип. Это автоматически означает, что он не может вместить в себя всё то множество чисел, которое может вместить в себя LARGE_INTEGER.

CDec("18446744073709551615") - это максимально возможное LARGE_INTEGER. 0 - минимальное. Значит весь диапазон охватывается.

[Хакер]

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

Это двойная работа. Проверка не легче, чем преобразование строки с числом в число с нуля.

Val/CDec:
12gorod считают нормальным числом и возвращают 12 (только Val).
& считают нормальным числом и возвращают 0 (только Val).
&head считается нормальным числом и возвращает 3757.
&O10 считается нормальным числом и возвращает 8.
5e+5 считается нормальным числом и возвращает 500000.
() считается нормальным числом и возвращатся ноль (только Val).
(123) считается нормальным числом и возвращается: Val возвращает ноль, а CDec возвращает минус 123.

Многие из этих правил кажутся логичным программисту, а некоторые кажутся откровенными глюками. Но рядового пользователя, не являющегося программистом, все эти случаи ошеломят.

[Qwertiy]

все эти случаи ошеломят

А может не надо всякую фигню в поле ввода писать тогда?

[Хакер]

Нет. Не надо перекладывать на пользователя свои программистские заботы. Следить за правильность ввода, отвергать некорректные входные данные — задача программы. Защита от дурака — забота программиста. Не нужно делать её с мыслью «да пусть просто пользователь не будет дураком».

[iGrok]

А может не надо всякую фигню в поле ввода писать тогда?

http://cs10742.userapi.com/u115464932/1 ... 8858a4.jpg

[Qwertiy]

Не нужно делать её с мыслью «да пусть просто пользователь не будет дураком».

Я не об этом.

Моё мнение такое: если можно интерпритировать нечто как допустимое значение, то именно так и следует сделать. Итогового подтверждения с указанием числа 3757 вполне достаточно. Если пользователь писал всякую ерунду просто чтобы поэксперементировать, то этого вполне достаточно. В любом случае, нажмёт кнопочку Назад и поменяет, если надо. А может, кому-то размер будет лень считать, поэтому он напишет &H80 GB - почему бы нет?

[sosed213]

Хакер, поделись идеей реализации такой проверки.

Судя по

В моих серьёзных программах (не поделках для себя) не используются функции Val и atoi.

становится ясно что такой вариант существует, и ты его используешь. (Если только это не сводится к созданию функции Function StringToLong (byval strIn as Variant, ... Byval куча критериев...) as Long (или LARGE_INTEGER)))

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

[Хакер]

Хакер, поделись идеей реализации такой проверки.

Никогда у меня не будет отдельной проверки и отдельной конвертации. Всегда интегрированная друг-в-друга проверка и конвертация. Иные решения противоречат принципу лени.

(Если только это не сводится к созданию функции Function StringToLong (byval strIn as Variant, ... Byval куча критериев...) as Long (или LARGE_INTEGER)))

Сводится.
У меня сейчас отключён от компьютера жесткий диск с исходниками, но выглядит это примерно так:
http://share.fire-lines.ru/firehacker/p ... age_01.jpg (Си, а не VB).

[Mikle]

Всегда интегрированная друг-в-друга проверка и конвертация. Иные решения противоречат принципу лени.

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

[sosed213]

Прошу прощения, если скажу глупость.
Но чем может быть плох простой способ:

Код: Выделить всё

If Not(Trim(Text1.Text) = CStr(Val(Trim(Text1.Text)))) Then
   Msgbox "Введены некорректные данные"
   Exit sub
end if

Т.е. Строку переводим в число, а затем это число в строку и сравниваем с первоисточником.
Если изначально присутствовал посторонний символ, то и строки будут не равны, а значит, что нужно изменить вводимое значение.
Можно добавить CStr(cLng(Val(Trim(Text1.Text)))) , если надо чтобы число было целым.

А глупым вопрос может оказаться из-за:

Не нужно быть беспечным. Не нужно перекладывать ответственность по обработки строчки и её конвертации в число с себя на библиотеку функций языка.

[Mikle]

Прошу прощения, если скажу глупость.
Но чем может быть плох простой способ:

Сделай так:

Код: Выделить всё

Option Explicit

Private Sub Text1_Change()
  Caption = ((Trim(Text1.Text) = CStr(Val(Trim(Text1.Text)))))
End Sub

Попробуй вводить - сразу сам увидишь, где проблемы. Ты ведь уже это спрашивал, и тебе отвечали, ты даже писал в ответ "хм, ага". Или ты поспал ночь, мозг обнулился - и теперь задаёшь те же вопросы заново?
Вообще, ты пытаешься написать процедуру проверки, не определившись с тем, что же считать корректным. Скажем так: "корректными считаются только целые положительные числа в пределах от N1 до N2, допустима только десятичная система счисления без использования степенного формата записи".

[sosed213]

Хм, ага - означает согласие, о неравенстве

Ага, получается поверка "+5" = "5", а это False

А изначально я и считал так:

Скажем так: "корректными считаются только целые положительные числа в пределах от N1 до N2, допустима только десятичная система счисления без использования степенного формата записи".

[Mikle]

А изначально я и считал так

Тогда, может, просто запретить ввод всего, кроме цифр?
И, если ты так считал, то где в твоей ф-ции проверки сравнение с N1 и N2, отсев дробей, отрицательных?

Хм, ага - означает согласие, о неравенстве

, а "05" - тоже некорректный ввод?

[sosed213]

И, если ты так считал, то где в твоей ф-ции проверки сравнение с N1 и N2, отсев дробей, отрицательных?

Теперь я понял в чем плох мой способ. Спасибо Mikle.

А (05 <> 5) , так что тоже не корректный ввод будет.

[arthur2]

Это двойная работа. Проверка не легче, чем преобразование строки с числом в число с нуля.

Нет, это не двойная работа.

Давай вспомним условия задачи: вводиться будут размеры в байтах Но что-то я сомневаюсь, что, скажем, 150 гигов целесообразно вводить именно в байтах. Так что самое правильное - просить ввести число в гигобайтах, а потом преобразовывать уже в байты. Так что твое парсение строки, выражающей число именно в байтах, окажется просто не нужным.

Как вариант решения: текстовое поле, в котором можно вводить только цифры (ну, пусть ещё запятые). Ни какие скобки, плюсы и минусы не нужны, в двоичном, восьмеричном или шестнадцатиричном виде вводить число тоже вряд ли кому понадобиться. Рядом с текстовым полем - листбокс с допустимыми единицами измерения. (если всё ж таки понадобится ввод в шестнадцатиричном или ещё каком виде, можно перед текстовым полем расположить ещё один листбокс со всеми допустимыми префиксами)

Теперь введенную строку переводим в число (сразу в вариант через CDec) и умножаем на нужный коэффициент в зависимости от единиц измерения. Мало того, с полученным числом можно делать разные арифметические действия, причем, без каких-либо ухищрений. И уже потом - моей функцией - можем легко перевести результат в LARGE_INTEGER.

[sosed213]

arthur2, это лучший вариант. поле для ввода + лист бокс с ед. измерения (Mb, Gb и Tb). Даже запятую не нужно использовать. А вводится будет, только в десятичном виде.

Спасибо

[Хакер]

Артур, я сейчас в Омске, с очень дорогим и медленным интернетом, и не могу много писать. Когда я вернусь домой — обязательно отвечу.
А пока коротко: ты не прав. Это двойная работа, и вот это «что твое парсение строки, выражающей число именно в байтах» — исключительно твоя фантазия.

[sosed213]

Омске?!?!?! Заезжай в гости!!! Чаем напою!

[arthur2]

Единственный правильный в твоём случае код, это код, который пройдётся по строке и на основании этого сам заполнит поля LARGE_INTEGER-а. Без всяких там Val и CDec

и вот это «что твое парсение строки, выражающей число именно в байтах» — исключительно твоя фантазия

Если эта строка, на основании которой предлагается заполнять LARGE_INTEGER - число не в байтах, а в каких-то других единицах, то число на выходе вполне уместится в лонг и пихать его в LARGE_INTEGER на этом этапе - смысла нет. CDec позволит производить с числом любые арифметические действия без ухищрений (если же заполнять именно LARGE_INTEGER - для всей арифметики придется писать специальные функции). А раз в строке ещё на этапе ввода будут отфильтрованы все неподходящие варианты, то Val сработает вполне корректно. Так что ни какой двойной работы с моим подходом - не вижу.

[sosed213]

Артур, твой способ хороший, и мне подходит. Только я CopyMemory заменил на GetMem и PutMem.

[arthur2]

sosed213 Да я понял, что тебе этот способ подошел Про путмем тоже очевидно - с копимемери я просто экспериментировал, когда ещё просто не понятно было, сколько, куда и чего придется копировать У себя я тоже заменил на путмемы.

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

[Хакер]

Я вернулся, но объяснять как-то влом. Собственно, ты встал в позу и игнорируешь, что плохой способ является плохим. Я сейчас потрачу время на написание поста, и ты ещё придумаешь какие-нибудь оправдания тому, что можно использовать Val/CDec.

[arthur2]

Ни в какую позу я не вставал. Я действительно не вижу, чем плох мой подход.

[Хакер]

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

Во-первых, оно может быть как в каких-то других единицах, так и в байтах в том числе. Это первая твоя ошибка.
Подчёркнутая часть — вторая твоя ошибка. Если в качестве единиц указаны килобайты, ты не опишешь диски размером больше 2 Tb. Кем надо быть, чтобы сознательно писать дисковую утилиту, не умеющую работать с дисками больше 2 Тб?

А раз в строке ещё на этапе ввода будут отфильтрованы все неподходящие варианты, то Val сработает вполне корректно. Так что ни какой двойной работы с моим подходом - не вижу.

Как можно сначала писать о фильтрации, а потом говорить, что никакой двойной работы не видишь? Это шутка или что? Ты сам пишешь о двойной работе: сначала проверка ввода, потом преобразование в не тот тип, который нужно, и в конце пеобразование в тот тип, который нужно.

Я говорю:
Нужен код, который преобразует строку в LARGE_INTEGER, автоматически проверив при этом правильность строки.

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

Чей способ соответствует этому топику, а чей противоречит? В чьём способе больше дополнительной работы, которая не нужна для дела, а привлекается исключительно для того, чтобы писать меньше кода?

[sosed213]

Кем надо быть, чтобы сознательно писать дисковую утилиту, не умеющую работать с дисками больше 2 Тб?

Кстати говоря, диск инициализированный как MBR и не может превышать 2 Тб. К сведению: в Microsoft Windows диск можно инициализировать как MBR так и GPT, есть еще и 3 вариант, RAW, но он вряд ли понадобится.
GPT жесткий диск может значительно превышать объем 2 Тб.

Так если я пишу программу для работы только с MBR дисками (пока) то 2 Тб мне вполне хватит.


P.S. Фраза "Кем надо быть..." по мойму немного резковата.

[arthur2]

Оk, оде лени мой подход не соответствует. Зато часть про ограничение неправильного ввода - соответствует, на мой взгляд, удобству пользователя.

Нужен код, который сначала проверит правильность строки

Я бы делал проверку ввода в любом случае - каким бы способом там дальше ни преобразовывалась строка в число. Так что первый "ненужный код" я считаю нужным. А раз строка после ввода будет заведомо корректной, не вижу преимуществ в самописной Val перед стандартной.

потом код, который преобразует строку в ненужный (но удобный лентяям) тип, и потом код, который преобразует ненужный тип в LARGE_INTEGER.

"Ненужный, но удобный тип" я как раз считаю нужным - именно по причине удобства. И тут дело даже не в лени - я сомневаюсь, что самописная арифметика для LARGE_INTEGER будет работать лучше или хотя бы не хуже, чем стандартная арифметика с "ненужным" типом. Поэтому и предлагаю преобразовывать в LARGE_INTEGER только тогда, когда это непосредственно понадобится.

Если в качестве единиц указаны килобайты, ты не опишешь диски размером больше 2 Tb

Описывать в килобайтах диск, размер которого больше двух терабайт - это какая-то редкая форма мазохизма Впрочем, мой код такому мазохизму не мешает - можно описывать хоть в байтах.

[Хакер]

Я бы делал проверку ввода в любом случае - каким бы способом там дальше ни преобразовывалась строка в число. Так что первый "ненужный код" я считаю нужным.

В способе с функция DecimalStringToLongInt эта проверка является неотъемлемой частью преобразования. А у тебя она — дополнительный самостоятельный код.

И тут дело даже не в лени - я сомневаюсь, что самописная арифметика для LARGE_INTEGER будет работать лучше или хотя бы не хуже, чем стандартная арифметика с "ненужным" типом.

Безосновательные страхи.

Поэтому и предлагаю преобразовывать в LARGE_INTEGER только тогда, когда это непосредственно понадобится.

Ты не предложил способа конвертации.

Описывать в килобайтах диск, размер которого больше двух терабайт - это какая-то редкая форма мазохизма

Это не наше дело. Наше дело — бысть настолько прозрачными, насколько это возможно. Вот есть например текстовые редакторы. В одних можно открыть EXE-файл, поменять единичку на единичку, сохранить, и EXE-файл будет работать. В других, если сделать то же самое, EXE-файл безвозвратно повреждается. Потому что редакторы непредсказуемо обходятся с непечатными символами; авторы подумали: фигали, это же текстовый редактор, кому может понадобиться им редактировать бинарные файлы? Вот авторыпоследних должны гореть в аду, я считаю. Программа должна быть прозрачной и никогда не отвергать и не искажать тех данных, которые по мнению её автора не входят в множество популярных вариантов входных данных.