Ассемблерные вставки и переносимость кода

← →
KSergey © (2012-06-14 10:00) [0]

1. С интересом прочитал бы размышления Розыча и не только относительно переносимости кода с ассемблерными вставками.

2. С интересом прочитал бы размышления участников форума относительно преимуществ типизированных указателей над нетипизированными.

← →
oxffff © (2012-06-14 10:14) [1]

> KSergey © (14.06.12 10:00)

В чем вопрос по 2?

← →
Rouse_ © (2012-06-14 10:15) [2]

А в чем проблема с переносимостью? :)
Если требуется жесткая привязка к асму (ну например потому что некоторые асм инструкции не вызываются напрямую как-то sysenter) то пишутся два аналога, помещающиеся под директивы компилятора. EAX меняем на RAX и вся не долга, или ты думаешь там все мудренее, чем кажется? :)
Другое дело если имеем конкретный 32 битный проект, который никто не собирается переводить на 64 бита, то проблема с переносимостью вообще банально высосана из пальца :)

← →
Давайте будем жрать! (2012-06-14 10:15) [3]

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

← →
Ega23 © (2012-06-14 10:17) [4]

> преимуществ типизированных указателей над нетипизированными.

procedure TForm44.Button1Click(Sender: TObject); var p1: PByte; p2: PWord; p3: PInteger; begin p1 := nil; p2 := nil; p3 := nil; Inc(p1); Inc(p2); Inc(p3); ShowMessage(IntToStr(Integer(p1)) + " " + IntToStr(Integer(p2)) + " " + IntToStr(Integer(p3))); end;

← →
Давайте будем жрать! (2012-06-14 10:18) [5]

> Ega23 © (14.06.12 10:17) [4]
Результат от директив компилятора зависит начиная (кажется) с XE.

← →
Ega23 © (2012-06-14 10:22) [6]

> Результат от директив компилятора зависит начиная (кажется) с XE.

У меня нет ХЕ, ничего по этому поводу сказать не могу.

← →
KSergey © (2012-06-14 10:27) [7]

> Ega23 © (14.06.12 10:17) [4]

Это отличие, вернее, это допустимые операции.
С нетипизироваными указателями операции инкремента/декремента (ну и т.п.) просто неприменимы.
Как можно просто наличие свойства называть преимуществом?

То, что соль соленая - это ее преимущество перед сахаром? так получается.

← →
KSergey © (2012-06-14 10:28) [8]

> Давайте будем жрать! (14.06.12 10:18) [5]
> Результат от директив компилятора зависит начиная (кажется) с XE.

Конкретный результат (в цифрах) не важен сейчас.

← →
KSergey © (2012-06-14 10:29) [9]

> Давайте будем жрать! (14.06.12 10:15) [3]
> Вообще-то в первоначальной ветке вопрос ставился иначе.

Считаете, это принципиально?

← →
KSergey © (2012-06-14 10:30) [10]

> oxffff © (14.06.12 10:14) [1]
> В чем вопрос по 2?

Да кабы я знал.
Вот так он был сформулирован Розычем. (Правда тут подсказывают, что с точностью до наоборот, но я не улавниваю разницы, признаться.)

← →
KSergey © (2012-06-14 10:31) [11]

> Rouse_ © (14.06.12 10:15) [2]
> А в чем проблема с переносимостью? :)
> Если требуется жесткая привязка к асму (ну например потому
> что некоторые асм инструкции не вызываются напрямую как-
> то sysenter) то пишутся два аналога, помещающиеся под директивы
> компилятора. EAX меняем на RAX и вся не долга,

Это вот называется переносимость, я правильно понял?

← →
Rouse_ © (2012-06-14 10:32) [12]

> Это отличие, вернее, это допустимые операции.

Это все что ты видишь ?:)

> С нетипизироваными указателями операции инкремента/декремента
> (ну и т.п.) просто неприменимы.

Да ну?
P: Pointer; begin P := PAnsiChar(P) + 100;

← →
Rouse_ © (2012-06-14 10:34) [13]

> Это вот называется переносимость, я правильно понял?

Это поддержка 64 битных компиляторов.

← →
KSergey © (2012-06-14 10:38) [14]

> Rouse_ © (14.06.12 10:32) [12]

Я правильно понимаю, что + 100 применено к нетипизированному указателю?
Розыч, зачем ты пытаешься обмануть?

← →
Rouse_ © (2012-06-14 10:39) [15]

> Я правильно понимаю, что + 100 применено к нетипизированному
> указателю?

Я же даже тип указателя привел :)

← →
KSergey © (2012-06-14 10:40) [16]

> Rouse_ © (14.06.12 10:34) [13]
> > Это вот называется переносимость, я правильно понял?
> Это поддержка 64 битных компиляторов.

Т.е. переписывание кода (а его придется внимательно переписать, т.к., очевидно, реальный код не ограничивается одной операцией сложения 2-х регистров) - это и называется "переносимость"?

Ну тогда речь о различном толковании терминов.

Это, кстати, одна из проблем собеседований бывает. Впрочем, любых так сказать "коммуникаций".

← →
Давайте будем жрать! (2012-06-14 10:42) [17]

> Считаете, это принципиально?
Ну, "там" было что-то вроде "преимущества т.у. над н.т.у и наоборот", а в данной ветке получается, что преимущества нетипизированных над типизированными не обсуждаются — не то ввиду очевидности, не то ввиду отсутствия... По-моему, это довольно сильно меняет вопрос.

← →
KSergey © (2012-06-14 10:42) [18]

> Rouse_ © (14.06.12 10:39) [15]
> Я же даже тип указателя привел

...к типу PAnsiChar

Розыч, я не понимаю зачем обманывать и выкручиваться?

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

← →
Rouse_ © (2012-06-14 10:44) [19]

>
> Т.е. переписывание кода (а его придется внимательно переписать,
> т.к., очевидно, реальный код не ограничивается одной операцией
> сложения 2-х регистров) - это и называется "переносимость"?
>

Нет ты видимо не допонял. В рамках переносимости, код с асм вставками будет скомпилирован на любой дельфи начиная от двойки до хе2(в 32 битах) и FP. Тут проблем не будет. Если требуется поддержка другой разрядности, код естетсвенно должен дописыватся, по примеру того как это сделано в system.pas от этого никуда не уйти, а что ты хотел, тут ничего универсального но оптимизированного не придумать.

← →
KSergey © (2012-06-14 10:44) [20]

> Давайте будем жрать! (14.06.12 10:42) [17]
> Ну, "там" было что-то вроде "преимущества т.у. над н.т.
> у и наоборот", а в данной ветке получается, что преимущества
> нетипизированных над типизированными не обсуждаются

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

← →
Rouse_ © (2012-06-14 10:46) [21]

> ...к типу PAnsiChar
>
> Розыч, я не понимаю зачем обманывать и выкручиваться?

Кто выкручивается? :) Ты сказал что к типизированным операция декремента не применяется - я показал что это не так :) То что инкремент был сделан через приедение,это значит я выкручиваюсь? Ты слишком большого мнения о бо мне :) Тем более данный пример можно написать и по другому, P := Pointer(DWORD(P) + 100) сути этого не поменяет. А вот то что ты до сих пор не сказал одно из явных достоинств типизированных указателей, меня мягко говоря смущает :)

По поводу асма не понял - что там и чего тебе показывает? Разжуй

← →
KSergey © (2012-06-14 10:47) [22]

> Rouse_ © (14.06.12 10:44) [19]

То, что код скомпилируется - это нифига не переносимость. Не мне тебе рассказывать.
"Плавали, заем".

Так что, надеюсь, настаивать на переносимости кода с асм. вставками - надеюсь настаивать ты не будешь больше.

← →
KSergey © (2012-06-14 10:47) [23]

> Rouse_ © (14.06.12 10:46) [21]
> Кто выкручивается? :) Ты сказал что к типизированным операция
> декремента не применяется - я показал что это не так :)

Ты как раз показал, что это - именно так.

← →
Rouse_ © (2012-06-14 10:52) [24]

> Так что, надеюсь, настаивать на переносимости кода с асм.
> вставками - надеюсь настаивать ты не будешь больше.

Что значит не буду? :) Ты кажется не улавливаешь мою специфику. Я в той ветке четко обозначил позицию, есть проект - под него пишется код. Есть блоки асм кода (очень много). Данный проект пережил миграцию с шестой дельфи по 2009-ую без правок асма. Ты же говоришь за некую универсальный код, который портируется куда угодно. Так вот это нам мало того что не нужно, так еще и экономически не выгодно, стало быть с какого перепуга я должен отказываться. Я же речь вел о приеме к нам на работу, где все я сно и понятно а не в некое непонятное сообщество любителей портируемого кода? :)

← →
Rouse_ © (2012-06-14 10:55) [25]

Поэтому соответственно и при приеме на работу свободное владение асмом только приветствуется.

← →
KSergey © (2012-06-14 11:18) [26]

> Rouse_ © (14.06.12 10:52) [24]
> Данный проект пережил миграцию с шестой дельфи по 2009-ую без правок асма.

Т.е. "переносимый код" - это переносимый между версиями дельфи, причем снизу-вверх?!!

Н-да...

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

← →
KSergey © (2012-06-14 11:18) [27]

Так что там с преимуществами?

← →
oxffff © (2012-06-14 11:23) [28]

> Rouse_ © (14.06.12 10:32) [12]
>
> > Это отличие, вернее, это допустимые операции.
>
> Это все что ты видишь ?:)
>
>
> > С нетипизироваными указателями операции инкремента/декремента
>
> > (ну и т.п.) просто неприменимы.
>
> Да ну?
> P: Pointer;
> begin
> P := PAnsiChar(P) + 100;

Саша, не лукавь. Операция производится над типизированным указателем.

← →
Rouse_ © (2012-06-14 11:33) [29]

> Т.е. "переносимый код" - это переносимый между версиями
> дельфи, причем снизу-вверх?!!

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

> Саша, не лукавь. Операция производится над типизированным
> указателем.

Ну хорошо я там пример привел второй, без типизированного указателя.

> Так что там с преимуществами?

Ну так это ты мне и скажи.

← →
Anatoly Podgoretsky © (2012-06-14 11:39) [30]

> Rouse_ (14.06.2012 11:33:29) [29]

Там тоже приведение, но уже к целому, а народ хочет без приведения

← →
Rouse_ © (2012-06-14 11:42) [31]

> а народ хочет без приведения

Когда народ утверждал что инкрементить/декрементить нельзя он ничего не говорил о приведении :)

← →
oxffff © (2012-06-14 11:57) [32]

> Ну хорошо я там пример привел второй, без типизированного
> указателя.

P := Pointer(DWORD(P) + 100)?

Где здесь применяется оператор + к типу pointer?

← →
Rouse_ © (2012-06-14 12:01) [33]

> Где здесь применяется оператор + к типу pointer?

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

← →
oxffff © (2012-06-14 12:04) [34]

> Rouse_ © (14.06.12 12:01) [33]

В Rouse_ © (14.06.12 10:32) [12].

← →
oxffff © (2012-06-14 12:09) [35]

> Здесь производится инкремент пойнтера через приведение,

Здесь приводится приведение к unsigned int, который увеличивается на 100, далее результат приводится к pointer. Это разные вещи.

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

В GC куче такие операции запрещены.

← →
Rouse_ © (2012-06-14 12:09) [36]

> oxffff © (14.06.12 12:04) [34]
> В Rouse_ © (14.06.12 10:32) [12].

А где я тут сказал? Процитируй.

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

function IncPointer(Value: Pointer): Pointer; overload; asm inc eax end; function IncPointer(Value: Pointer; Size: Integer): Pointer; overload; asm add eax, edx end;

← →
Rouse_ © (2012-06-14 12:11) [37]

> Здесь приводится приведение к unsigned int, который увеличивается
> на 100, далее результат приводится к pointer.

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

← →
oxffff © (2012-06-14 12:17) [38]

> Rouse_ © (14.06.12 12:09) [36]
>
> > oxffff © (14.06.12 12:04) [34]
> > В Rouse_ © (14.06.12 10:32) [12].
>
> А где я тут сказал? Процитируй.

Да ну, Саша.
Но тем не менее, понимаю тебя, поскольку ты человек который смотрит сквозь абстракции, но все же [35].

← →
oxffff © (2012-06-14 12:21) [39]

> Rouse_ © (14.06.12 12:11) [37]
>
> > Здесь приводится приведение к unsigned int, который увеличивается
>
> > на 100, далее результат приводится к pointer.
>
> Не Серег, там производится именно инкремент нетипизированного
> указателя, пойнтера :) Т.е. решается вполне конкретная задача
> :) Все остальное риторика...

Саш, предлагаю на MSIL написать тоже самое.

← →
oxffff © (2012-06-14 12:23) [40]

> Саш, предлагаю на MSIL написать тоже самое.

С условием того, что код должен остаться safe.

← →
Rouse_ © (2012-06-14 12:23) [41]

> Саш, предлагаю на MSIL написать тоже самое.

А зачем, когда есть типизированные указатели? :)

← →
Rouse_ © (2012-06-14 12:24) [42]

> С условием того, что код должен остаться safe.

см. [24]
В моих задачах это не актуально :)

← →
oxffff © (2012-06-14 12:25) [43]

> А зачем, когда есть типизированные указатели? :)

А еще лучше когда к ним есть еще и по 50 грамм. :)))

← →
Ega23 © (2012-06-14 12:29) [44]

> А еще лучше когда к ним есть еще и по 50 грамм. :)))

Это намёк?

← →
oxffff © (2012-06-14 12:30) [45]

> Ega23 © (14.06.12 12:29) [44]

Не вопрос. :)

← →
Rouse_ © (2012-06-14 12:34) [46]

> А еще лучше когда к ним есть еще и по 50 грамм. :)))

Да под шашлычек :)

Ладно, дабы добить тему про типизированные указатели.

> KSergey ©

Одно из самых пестрых преимуществ типизированных указателей проявляется когда мы работаем с указателями на массив структур (record). Перемещение по массиву производится обычным инкрементом/декрементом указателя, выборка данных разыменованием типизированного указателя. В этот момент нам не надо задумываться о оффсетах на нужный нам блок данных в рекорде, этим на автомате занимается компилятор. Казалось-бы мелочь, но многие в такую мелочь абсолютно не вникают и не пользуются данной возможностью...

← →
Rouse_ © (2012-06-14 12:39) [47]

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

← →
Дмитрий С © (2012-06-14 12:47) [48]

> многие в такую мелочь абсолютно не вникают и не пользуются
> данной возможностью...
>

А мне кажется наоборот, что многие даже не задумываются что происходит, работает и работает. Особенно учитывая, что дельфи разыменовывает указатель даже без ^.

← →
Омлет © (2012-06-14 12:50) [49]

> Rouse_ © (14.06.12 12:34) [46]

Кроме inc(p), ещё удобны sizeof(p^) и with p^ do для работы со структурами.

← →
Anatoly Podgoretsky © (2012-06-14 12:56) [50]

> oxffff (14.06.2012 12:25:43) [43]

А лучше по 100

← →
Rouse_ © (2012-06-14 12:58) [51]

> Особенно учитывая, что дельфи разыменовывает указатель даже
> без ^.

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

> Омлет © (14.06.12 12:50) [49]

Ну в принципе да, но это уже третьестепенного плана удобство (имхо) :)

← →
Дмитрий С © (2012-06-14 13:07) [52]

> Кроме inc(p), ещё удобны sizeof(p^) и with p^ do для работы
> со структурами.

Мне больше нравится:
var
x: array of ...
y: string;

...
SizeOf(x[0])
SizeOf(y[0])

← →
Омлет © (2012-06-14 13:16) [53]

> третьестепенного плана удобство

Да точно такое же - не надо приводить/указывать типы.
Для нетипизированного:
inc(NativeInt(p), sizeof(TMyMegaSuperRec)) sizeof(TMyMegaSuperRec) with PMyMegaSuperRec(p)^ do

Для типизированного:
inc(p) sizeof(p^) with p^ do

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

> Дмитрий С © (14.06.12 13:07) [52]
> Мне больше нравится:
> SizeOf(x[0])

И причем тут указатели?

← →
Омлет © (2012-06-14 13:23) [54]

А ещё в D2009 появилась директива POINTERMATH.
http://blogs.embarcadero.com/abauer/2008/01/24/38852

← →
Дмитрий С © (2012-06-14 13:23) [55]

> И причем тут указатели?

А по твоему строки и динамические массивы это не указатели?

← →
Омлет © (2012-06-14 13:30) [56]

> А по твоему строки и динамические массивы это не указатели?

Да, по-моему, это не указатели.

← →
Anatoly Podgoretsky © (2012-06-14 13:39) [57]

Самы что ни на есть указатели, там переменная не сам массив, а указатель на массив, в отличии от статических. Вся кузня скрыта.

← →
KSergey © (2012-06-14 14:44) [58]

> Rouse_ © (14.06.12 12:34) [46]
> Одно из самых пестрых преимуществ типизированных указателей
> проявляется когда мы работаем с указателями на массив структур (record).

Продолжаешь нести ахинею по поводу того, что соль лучше сахара тем, что она соленая.
Я прямо удивлен весь.

> Rouse_ © (14.06.12 12:09) [36]
> function IncPointer(Value: Pointer): Pointer; overload;
> asm
> inc eax
> end;

И где здесь инкремент нетипизированного указателя?
Ну и переносимость кода опять выше всяких похвал.

Впрочем, упорное повторение фразы "мне в моих проектах..." уже мне все пояснила.
Спасибо, я понял.

Продолжайте вариться в своём котле.

← →
Cobalt © (2012-06-14 14:57) [59]

Саш, а вот расскажи по x32 - x64
Я сам ассемблером с 1-го курса технаря не занимался, потому мне интересно:
допустим, есть asm-процедура типа
function IncValue(Value: Integer): Integer; overload; asm inc eax end;
скажи, при переходе на x64 что изменится?

← →
Rouse_ © (2012-06-14 15:17) [60]

> Продолжаешь нести ахинею по поводу того, что соль лучше
> сахара тем, что она соленая.
> Я прямо удивлен весь.

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

> И где здесь инкремент нетипизированного указателя?

он прямо перед тобой. Покажи мне где тут его нет?

> Ну и переносимость кода опять выше всяких похвал.

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

> Продолжайте вариться в своём котле.

А вот хамить не стоит.

← →
Rouse_ © (2012-06-14 15:20) [61]

> скажи, при переходе на x64 что изменится?

у меня нет под рукой 64 бит компилера, но в зависимости от размера, либо останется как есть, либо нужно будет переписать данный конкретный пример как
function IncValue(Value: Integer): Integer; overload; asm inc rax end;

← →
MBo © (2012-06-14 15:30) [62]

первый параметр теперь rcx, но возврат функции - rax

Calling conventions. Delphi x64 supports only single calling convention - Microsoft x64 calling convention (first 4 parameters passed on rcx/xmm0; rdx/xmm1, r8/xmm2, r9/xmm3). All other conventions, like stdcall, pascal are synonyms for this one.

The registers RCX, RDX, R8, R9 are used for integer and pointer arguments (in that order left to right), and XMM0, XMM1, XMM2, XMM3 are used for floating point arguments. Additional arguments are pushed onto the stack (right to left). Integer return values (similar to x86) are returned in RAX if 64 bits or less. Floating point return values are returned in XMM0. Parameters less than 64 bits long are not zero extended; the high bits contain garbage.

← →
Rouse_ © (2012-06-14 15:38) [63]

> MBo © (14.06.12 15:30) [62]
>
> первый параметр теперь rcx, но возврат функции - rax

О, нюанс... но как я и говорил 64 бит у меня нет, поэтому спецификацию еще не изучал.
С учетом нюанса тогда:

function IncValue(Value: Integer): Integer; overload; asm lea rax, [rcx + 1] end;

← →
Anatoly Podgoretsky © (2012-06-14 15:39) [64]

> Rouse_ (14.06.2012 15:20:01) [61]

Не так
asm {$ifdef} Флаг64бит inc rax else inc eax endif end;

← →
KSergey © (2012-06-14 15:41) [65]

> Rouse_ © (14.06.12 15:17) [60]

Как это можно объяснить человеку, который не видит разницу между регистром процессора и указателем? почему регистр увеличивается именно на 1 - тоже не понятно, кстати.
Да еще приводит нетипизированный указатель к типизированному, упорно делая вид, что этого нет.

Александр, уверен, ты все понимаешь, но зачем-то не желаешь признать специфичную трактовку тобою терминов.
Зачем ты это делаешь - мне не понять.

> Rouse_ © (14.06.12 15:20) [61]

Integer на x64 платформе - 32-х битное. (если честно, именно про дельфи не сумел найти инфу; вдруг возбладает разум и Integer в дельфи таки 64-х битный будет? но надежды мало).
Лично мне философия этого совершенно не ясна, тем более, что я отлично помню, как ЮЗ на этом форуме писал, что когда в микропроцессорах Integer не будет равен размеру указателя - мир перевернется. И я с ним был горячо согласен.
Как жить дальше - и не знаю.

← →
KSergey © (2012-06-14 15:42) [66]

> MBo © (14.06.12 15:30) [62]

Вау! Все еще лучше с переносимостью оказалось.

← →
Rouse_ © (2012-06-14 15:52) [67]

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

В 32 битных системах? Расскажи мне разницу.

> почему регистр увеличивается именно на 1 - тоже не понятно,
> кстати.

Ты видимо специально выдираешь слова из контекста. Я кажется даже прокоментировал данный код, а именно:

> Если бы я захотел решить инкремент самого пойнтера, то мне
> пришлось бы обойти ограничение накладываемое компилером,
> ну что-то вроде:

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

> Да еще приводит нетипизированный указатель к типизированному,
> упорно делая вид, что этого нет.

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

> не желаешь признать специфичную трактовку тобою терминов.

Я не желаю признавать голословных утверждений.
Ты не ответил ни на один из поставленных мной вопросов, зачем то начал опять не с того, что я спросил в [60].

Все что я услышал из твоих заявлений это:
1. соль лучше сахара тем, что она соленая.
2. с нетипизироваными указателями операции инкремента/декремента просто неприменимы.
3. у полностью и категорично везде не прав.

Это все что я услышал.

Я же пример примеры и разьяснения с разжовыванием и опять оказываюсь не прав по твоей логике. Что-то тут не так...

← →
KSergey © (2012-06-14 15:52) [68]

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

Собственно я уже выяснил для себя заботящую меня суть вопроса: она оказалась в терминологии. Результат вполне нормальный, он все объясняет. (При этом не имеет положительной или отрицательной окраски!)

← →
Rouse_ © (2012-06-14 15:54) [69]

> Anatoly Podgoretsky © (14.06.12 15:39) [64]

Тогда уж лучше:
function IncValue(Value: Integer): Integer; asm {$IFDEF CPUX64} lea rax, [rcx + 1] {$ELSE} inc eax {$ENDIF} end;

← →
ProgRAMmer Dimonych © (2012-06-14 15:56) [70]

> [68] KSergey © (14.06.12 15:52)
> В общем преимуществ у нетипизированных указателей перед
> типизированными - нет.

Тогда зачем они оставлены в языке? Почему не убрать Pointer насовсем?

← →
Rouse_ © (2012-06-14 16:01) [71]

> В общем преимуществ у нетипизированных указателей перед
> типизированными - нет.

Ну блин, задаешь один вопрос, отвечаешь вообще на другой.

> KSergey © (14.06.12 10:00)
> 2. С интересом прочитал бы размышления участников форума
> относительно преимуществ типизированных указателей над нетипизированными

← →
KSergey © (2012-06-14 16:01) [72]

> Rouse_ © (14.06.12 15:52) [67]
> > между регистром процессора и указателем?
> В 32 битных системах? Расскажи мне разницу.

Ага, уже пошли уточнения, уже хорошо.
Разница проста: у процессора - есть регистры, но нет указателей.
В Дельфи - нет регистров (хотя это спорно, вроде есть зарезервированные переменные, привязанные к регистрам процессора? или я путаюсь?), но есть указатели.
Вот и вся разница.

> Ну так ты же ничего не говорил о приведении, а теперь начинаешь
> оправдываться что мол это я виноват, как-же так я же сжульничал.

Предлагаю прекратить клоунаду, на которую, к слову, указали несколько участников.

Относительно недоговоренностей - кто бы говорил ;) Исходные вопросы кишели таковыми. Что, собственно, и выяснилось в ходе этой ветки и прояснило видение участвующих, что, как я уже писал, вполне годный результат.

2. с нетипизироваными указателями операции инкремента/декремента просто неприменимы.

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

← →
KSergey © (2012-06-14 16:08) [73]

> ProgRAMmer Dimonych © (14.06.12 15:56) [70]
> Тогда зачем они оставлены в языке? Почему не убрать Pointer насовсем?

Pointer удобно использовать для передачи указателя на "универсальный контент" (во всяких call-back функциях, к примеру), т.к. его можно присваивать любому типизированному указателю. Ну и случайно не заинкрементируешь по дороге, опять же удобно.

← →
Rouse_ © (2012-06-14 16:09) [74]

> Вот и вся разница.

А в чем разница?

> Предлагаю прекратить клоунаду, на которую, к слову, указали
> несколько участников.

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

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

Щас еще раз специально перечитал ту ветки - чей-то не нашел, уточни...

> Искренне надеюсь, что ты не будешь с этим спорить.

Спорить с чем? Если бы ты сказал что компилятор не позволяет проводить операции инкремента/декремента над нетипизированными указателями, то конечно бы не спорил, ибо это так.
Ты же сказал что такие операции не применимы, т.е. не делаются, нельзя, табу, не заработает. С этим конечно стоит спорить, а почему-бы и нет?

← →
KSergey © (2012-06-14 16:11) [75]

> Rouse_ © (14.06.12 16:01) [71]
>
> > В общем преимуществ у нетипизированных указателей перед
>
> > типизированными - нет.
>
> Ну блин, задаешь один вопрос, отвечаешь вообще на другой.
>
> > KSergey © (14.06.12 10:00)
> > 2. С интересом прочитал бы размышления участников форума
>
> > относительно преимуществ типизированных указателей над нетипизированными

Родной, ты понимать умеешь написанное?
Специально для тебя:

В общем преимуществ у [b]типизированных[/b] указателей перед [b]ytтипизированными[/b] - нет.
Есть просто операции, которые применимы к только к одному, но не применимы к другому типу указателей. Но называть это "преимуществами" вообще - странно.

← →
Anatoly Podgoretsky © (2012-06-14 16:14) [76]

> Rouse_ (14.06.2012 15:54:09) [69]

Конечно, я не стал поправляться после твоего код и не видел еще модели
вызова, у меня ведь тоже нет XE2,
но суть то в том, что бы обвешать Ифами

← →
ProgRAMmer Dimonych © (2012-06-14 16:15) [77]

> [73] KSergey © (14.06.12 16:08)
> > ProgRAMmer Dimonych © (14.06.12 15:56) [70]
> > Тогда зачем они оставлены в языке? Почему не убрать Pointer
> насовсем?
>
> Pointer удобно использовать для передачи указателя на "универсальный
> контент" (во всяких call-back функциях, к примеру), т.к.
> его можно присваивать любому типизированному указателю.
> Ну и случайно не заинкрементируешь по дороге, опять же удобно.

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

← →
Rouse_ © (2012-06-14 16:17) [78]

> Родной, ты понимать умеешь написанное?
> Специально для тебя:

Я же тебе сказал - не хами, не стоит...

> В общем преимуществ у [b]типизированных[/b] указателей перед
> [b]ytтипизированными[/b] - нет.

Печально что ты так все видишь.
Типизированный указатель в отличие от типизированного имеет размер на который опирается new/dispose, инкрементируем, предоставляет возможность автоматического рассчета оффсетоф. Но это как я понял в твоем понимании соль, которая соленая. А так-то в принципе да - разницы нет...

← →
Rouse_ © (2012-06-14 16:18) [79]

> в отличие от нетипизированного

← →
Дмитрий С © (2012-06-14 16:19) [80]

Вот интересно:
asm mov ebx, [eax] end;
Регистр, в данном случае, указатель или нет? :)

← →
Rouse_ © (2012-06-14 16:20) [81]

Регистр это регистр, он хранит данные, типа которых он не знает.

← →
Anatoly Podgoretsky © (2012-06-14 16:23) [82]

> ProgRAMmer Dimonych (14.06.2012 15:56:10) [70]

А что будешь делать с некими заранее неизвестными данными?
Там же даже конструкия есть спефиальная var Name без указания типа.

← →
Дмитрий С © (2012-06-14 16:24) [83]

А если регистр описан переменной типа PInteger, например, в языке это что-то меняет?

← →
ProgRAMmer Dimonych © (2012-06-14 16:26) [84]

> [82] Anatoly Podgoretsky © (14.06.12 16:23)
> > ProgRAMmer Dimonych (14.06.2012 15:56:10) [70]
> А что будешь делать с некими заранее неизвестными данными?
> Там же даже конструкия есть спефиальная var Name без указания
> типа.

Что продолжает [73] и [77].

← →
ProgRAMmer Dimonych © (2012-06-14 16:28) [85]

> [83] Дмитрий С © (14.06.12 16:24)

Так переменные и указателями отдельно, регистры и адреса - отдельно. Сущности с разных уровней абстракции.

← →
KSergey © (2012-06-14 16:29) [86]

> Rouse_ © (14.06.12 16:09) [74]
> На что я и попросил уточнить, о какой переносимости идет речь, если ее на данный момент в Дельфи, до ХЕ включительно,
> нет? Т.е. весь разговор свелся к некой мифической необходимости, возможности для осуществения которой отсутствуют.

"Отсутствует" лишь потому, что некоторые отвергают существование других компиляторов с ровно того Delphi Language, не знаю, согласен ли с этим названием FPC.
При этом прикрываются формальностями упомянутых (или подразумеваемых) слов.

← →
Rouse_ © (2012-06-14 16:29) [87]

> Дмитрий С © (14.06.12 16:24) [83]
>
> А если регистр описан переменной типа PInteger, например,
> в языке это что-то меняет?

Регистр не может быть описан чем-то, он может содержать в себе значение переменной PInteger, равно как и обычной Pointer/integer/cardinal и т.п.
Соответственно все операции применимые к integer работают и со всеми остальными. В данном случае мы обсуждаем ограничения наложенные компилером.

← →
Pavia © (2012-06-14 16:31) [88]

надо будет устроить голосование на самого жирного троля.

← →
KSergey © (2012-06-14 16:32) [89]

> Rouse_ © (14.06.12 16:17) [78]
> Я же тебе сказал - не хами, не стоит...

А как тебя еще в чувства приводить прикажешь, если очевидную клоунаду не прикращаешь?

← →
Дмитрий С © (2012-06-14 16:35) [90]

> Rouse_ © (14.06.12 16:29) [87]

Integer может хранить в себе тот же указатель.
Можно подумать, что никто никогда не хранил Integer в качестве TObject в стринглисте. Или не передавал указатель на объект в какой нибудь EnumWindows.

Integer, Pointer, P.... - это лишь 4 байта как и регистр, тип которого на самом деле находится в голове программиста. Компилятор лишь помогает не ошибиться.

> Сущности с разных уровней абстракции.

На практике эти уровни не так уж и абстрагированы (в delphi).

← →
KSergey © (2012-06-14 16:36) [91]

> Rouse_ © (14.06.12 16:17) [78]
> Типизированный указатель в отличие от типизированного имеет размер

Вопрос, напомню, был сформулирован про преимущества, а не свойства. Если бы про разницу - то и вопроса моего исходного бы не было.
Так в чем преимущество? т.е. чем один лучше/хуже другого, ведь преимущество (а не просто разные качества) подразумевает именно это.

← →
Дмитрий С © (2012-06-14 16:37) [92]

> KSergey © (14.06.12 16:32) [89]

Оба вопроса [0] - троллинг. Теперь еще и на личности перешел.

← →
Дмитрий С © (2012-06-14 16:38) [93]

> Так в чем преимущество?

Такое же как преимущество топора перед молотком.

← →
KSergey © (2012-06-14 16:39) [94]

> ProgRAMmer Dimonych © (14.06.12 16:15) [77]
> Т.е. для определённых ситуаций преимущества всё же есть?
> Компромиссный вариант: есть свойства, которые в той или
> иной ситуации становятся преимуществами ил недостатками.

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

← →
Inovet © (2012-06-14 16:41) [95]

> [93] Дмитрий С © (14.06.12 16:38)
> Такое же как преимущество топора перед молотком.

У молотка преимущество. Молотком можно бить по топору, пока тот не превратится в молоток, потом ещё можно бить, пока молоток не превратится в топор.

← →
KSergey © (2012-06-14 16:44) [96]

> Дмитрий С © (14.06.12 16:37) [92]
> Оба вопроса [0] - троллинг.

Т.е. обращение вопроса к его автору - троллинг?!
Нифига себе.

← →
картман © (2012-06-14 16:45) [97]

> Такое же как преимущество топора перед молотком.

он к этому с самого начала ведет

← →
Дмитрий С © (2012-06-14 16:49) [98]

Удалено модератором

← →
Rouse_ © (2012-06-14 16:52) [99]

> "Отсутствует" лишь потому

Я специально уточнял по поводу Дельфи. Причем постоянно, логично что разговор велся только в рамках данного продукта?
Впрочем даже о возможном решении я так-же рассказал, на что ты замечательно отписался о "замечательном портировании", причем не предложив даже свой вариант.

> KSergey © (14.06.12 16:32) [89]
> А как тебя еще в чувства приводить прикажешь, если очевидную
> клоунаду не прикращаешь?

Клоунаду? Я рассказываю очевидные вещи, самые банальные. На клоунаду и хамство скатываюсь отнюдь не я...

> KSergey © (14.06.12 16:36) [91]
> Вопрос, напомню, был сформулирован про преимущества, а не
> свойства.

Получается свойства, которые присутствуют у типа и отсутствуют у другово, это не преимущества? А что тогда? Просто свойства? И указатель с регистре это уже не указатель, а что-то другое? Ах, да - это видимо уже просто регистр :)

← →
KSergey © (2012-06-14 16:53) [100]

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

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

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

Где троллинг, где переход на личности - мне не понять.

← →
KSergey © (2012-06-14 16:54) [101]

Удалено модератором

← →
Anatoly Podgoretsky © (2012-06-14 16:57) [102]

> KSergey (14.06.2012 16:01:12) [72]

Указатель по английски Pointer/Address в АСМ можно помещать в регистр (для
косвенной адресации), может быть указан прямо в команде (для прямой
адресации)

← →
Anatoly Podgoretsky © (2012-06-14 17:01) [103]

> Дмитрий С (14.06.2012 16:19:20) [80]

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

← →
sniknik © (2012-06-14 18:13) [104]

> надо будет устроить голосование на самого жирного троля.
+1 за автора топика. в данной ветке.

← →
картман © (2012-06-14 18:29) [105]

голосую за TUser"a

← →
Kerk © (2012-06-14 18:34) [106]

Оба вы тролли. Один пытается доказать (кому? нафига?), что если выворачиваться через задницу, то в машинном коде все эквивалентно. Второй отказывается считать преимуществами то, что умеет один, но не умеет другой. Мда.

← →
Rouse_ © (2012-06-14 18:43) [107]

> то в машинном коде все эквивалентно

абсолютно верно, только выворачиваться не надо :)

← →
KSergey © (2012-06-14 18:59) [108]

> Rouse_ © (14.06.12 18:43) [107]
> > то в машинном коде все эквивалентно
> абсолютно верно, только выворачиваться не надо :)

Наверное хорошо бы отделять язык и его реализацию.

> Kerk © (14.06.12 18:34) [106]
> то в машинном коде все эквивалентно

MBo привел наглядную цитату того, что эквивалентно в очень узких рамках.

Я лишь пытался донести до Rouse_, что мир шире (при том, что он вообще-то это знает уж точно не хуже меня), при этом, замечу, вопросцы были с собеседа.

Впрочем, учитывая, что собесед помимо проверки технических знаний подразумевает и, так сказать, мировоззренческую подходящесть протестровать - то, вероятно, вопросы удачные )

← →
Rouse_ © (2012-06-14 19:41) [109]

> Я лишь пытался донести до Rouse_, что мир шире

Я в принципе понимаю что ты хотел сказать :) В общем-то я с твоими доводами согласен, но есть много нюансов, о которых я тебе и пытался целый день втолковать :)

← →
Rouse_ © (2012-06-14 21:13) [110]

> KSergey ©

зы, ну и с учетом что у меня сегодня был релиз 11-ти месячного проекта (15 мин назад закрыли), и то я оставался спокоен в споре, то даж не представляю что там у тебя творилось на работе :)

← →
Дмитрий С © (2012-06-14 22:20) [111]

> Я лишь пытался донести до Rouse_, что мир шире

Сначала ты попросил его мнения, затем обвинил в том, что он устраивает клоунаду, поэтому я назвал тебя таким словом.

> Где троллинг,

В самих вопросах. Не исключено, что на собеседе тебя пробовали потроллить :)

← →
Ega23 © (2012-06-14 22:59) [112]

Удалено модератором

← →
KSergey © (2012-06-15 07:51) [113]

> Ega23 © (14.06.12 22:59) [112]

Напиши мне почтой, я не успел прочитать.

← →
KSergey © (2012-06-15 07:54) [114]

> Дмитрий С © (14.06.12 22:20) [111]
> > Где троллинг,
> В самих вопросах.

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

Удивительно.

← →
Cobalt © (2012-06-15 08:43) [115]

Подкину дровишек :)
Какие преимущества у строки перед Integer?
/popcorn

← →
KSergey © (2012-06-15 09:18) [116]

> Cobalt © (15.06.12 08:43) [115]

В нее можно запихать число любой точности!

← →
Ega23 © (2012-06-15 09:24) [117]

> В нее можно запихать число любой точности!

Не любое, строка имеет ограничение :)

← →
Cobalt © (2012-06-15 09:24) [118]

О! идеальный формат для хранения значения "NAN"

← →
KSergey © (2012-06-15 09:31) [119]

> Не любое, строка имеет ограничение :)

Думаю, это неправильное утверждение.
Поясню. Если говорить об абстракции - то таки любое, ибо в абстракции ни числа, ни строки не имеют ограничений.
Если мы говорим о компьютере - то тоже любое, т.к. и строки, и возможные числа обязательно имеют ограничения разными конечными величинами (от ограничения размеров памяти, вне зависимости от ее типа, до конечности допустимого интервала времени на ввод/вывод чисел.
Ну в дельфи есть свое ограничение на строки, таки да, но ведь можно не встроенными в компилятор строками пользоваться.

← →
KSergey © (2012-06-15 09:34) [120]

> KSergey © (15.06.12 09:31) [119]
> Думаю, это неправильное утверждение.

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

при этом то, что строки имеют ограничение - само по себе утверждение, конечно, полностью верное )

← →
Ega23 © (2012-06-15 09:38) [121]

> Если мы говорим о компьютере - то тоже любое, т.к. и строки,
> и возможные числа обязательно имеют ограничения разными
> конечными величинами

Взаимоисключающие параграфы.

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

?

← →
KSergey © (2012-06-15 09:43) [122]

> Ega23 © (15.06.12 09:38) [121]
> Взаимоисключающие параграфы.

Не понял.

← →
KSergey © (2012-06-15 09:44) [123]

Кстати, кто недоволен стилем общения с уважаемыми людьми - может провести простейший эксперимент: регистрируешься на форуме другим ником и спрашиваешь/отвечаешь.
Эксперименты такие проводились и результаты впечатляют, доложу я вам.

← →
oxffff © (2012-06-15 09:47) [124]

> Cobalt © (15.06.12 09:24) [118]
> О! идеальный формат для хранения значения "NAN"
>
>

Стеб, не по существу.

← →
Омлет © (2012-06-15 09:48) [125]

> KSergey © (15.06.12 09:44) [123]

Хамство процветает?

← →
KSergey © (2012-06-15 09:53) [126]

> Омлет © (15.06.12 09:48) [125]
> Хамство процветает?

Спойлерить не буду.

← →
oxffff © (2012-06-15 09:54) [127]

Друзья, остановитесь.

← →
KSergey © (2012-06-15 09:58) [128]

> KSergey © (15.06.12 09:43) [122]
> > Взаимоисключающие параграфы.
> Не понял.

Серьезно, не понял.
Можно подробнее?

← →
Rouse_ © (2012-06-15 13:11) [129]

> KSergey © (15.06.12 09:58) [128]
> Серьезно, не понял.
> Можно подробнее?

Имелось ввиду что раз есть ограничение, то записать любое значение не получится...

← →
Cobalt © (2012-06-15 16:30) [130]

Удалено модератором

← →
KSergey © (2012-06-15 17:01) [131]

> Rouse_ © (15.06.12 13:11) [129]
> Имелось ввиду что раз есть ограничение, то записать любое значение не получится...

А я намекаю на то, что не удастся привести пример числа, которое невозможно записать (ну если сформулировать в формате "а вот напиши тут число, которое не удастся записать"), а раз не возможности привести пример того, что нельзя записать, значит записать можно любое :)

← →
Ega23 © (2012-06-15 17:06) [132]

> А я намекаю на то, что не удастся привести пример числа,
> которое невозможно записать

Да легко.
10000000000000000000000000000000^100000000000000000000000000000000000000

← →
картман © (2012-06-15 17:23) [133]

> Да легко.
> 10000000000000000000000000000000^100000000000000000000000000000000000000

длиннО

← →
KSergey © (2012-06-15 17:25) [134]

> Ega23 © (15.06.12 17:06) [132]

Я знал, что это кто-то напишет )
Это математическая операция, а не число, что не одно и тоже.
И саму операцию записать действительно можно, в отличии от результата.

← →
картман © (2012-06-15 17:27) [135]

ну на: http://ru.wikipedia.org/wiki/%D0%A1%D1%82%D1%80%D0%B5%D0%BB%D0%BE%D1%87%D0%BD%D0%B0%D1%8F_%D0%BD%D0%BE%D1%82%D0%B0%D1%86%D0%B8%D1%8F_%D0%9A%D0%BD%D1%83%D1%82%D0%B0

← →
KSergey © (2012-06-15 17:27) [136]

А если это таки считать числом - то ничто не мешает вот в таком виде это и хранить.

← →
Rouse_ © (2012-06-15 17:32) [137]

> А я намекаю на то, что не удастся привести пример числа,
> которое невозможно записать

Я пропустил немного, куда именно записать? Если в ShortString то это любое число больше 255 знаков. Если в обычную строку то любое число с числом знаков большим $80000000 (например PI)

← →
KSergey © (2012-06-15 17:39) [138]

> Rouse_ © (15.06.12 17:32) [137]
> Я пропустил немного, куда именно записать?

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

← →
Rouse_ © (2012-06-15 17:44) [139]

> была фраза "ничто не мешает сделать собственную какую угодно
> реализацию строки

А это большой роли не играет, ты упрешься в лимит 2 гига виртуальной памяти, в который то-же PI представленное в виде строки просто не влезет. Можно расширить до трех под 32 битами и не помню до скольки под 64 битами, но во всех трех случаях PI в виде строки не влазит (там сейчас более 10 триллионов цифр после запятой, т.е. памяти нуно оч много)

← →
Inovet © (2012-06-15 17:45) [140]

> [134] KSergey © (15.06.12 17:25)
> Это математическая операция, а не число, что не одно и тоже.

Дв ну. Вот тебе число - Пи.

← →
Inovet © (2012-06-15 17:46) [141]

> [137] Rouse_ © (15.06.12 17:32)
> куда именно записать?

Неважно, хоть в файле пусть хранится.

← →
KSergey © (2012-06-15 17:54) [142]

> Inovet © (15.06.12 17:45) [140]
> Дв ну. Вот тебе число - Пи.

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

← →
Rouse_ © (2012-06-15 18:07) [143]

> Так и записать в нее - Пи

Ну так это же не число, а его аббревиатура :)

Ага, 10000000000000000000000000000000^100000000000000000000000000000000000000 - число, а Пи - аббревиатура.

> KSergey © (15.06.12 18:14) [144]
>
> Ага, 10000000000000000000000000000000^100000000000000000000000000000000000000
> - число

Я разве это говорил? Я говорил другое, а именно что PI, представленное в виде строки до 10 триллионов знаков после запятой, ты не сможешь поместить в память приложения, что собственно (я надеюсь) и есть контраргумент на

> записать можно любое

> KSergey © (15.06.12 18:38) [146]

Блин, а я разве не привел пример такого числа? :))) Серег, я реально не понимаю, то ли ты меня зацепить хочешь, то ли... ну даже не понимаю :)

> Rouse_ © (15.06.12 18:41) [147]
> Серег,
> я реально не понимаю, то ли ты меня зацепить хочешь, то ли... ну даже не понимаю :)

Я не занимаюсь троллингом сознательным. Во всяком случае здесь и сейчас. Торжественно клянусь.

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

Именно потому я и пытаюсь эти самые различия в трактовке терминологии нащупать и сформулировать. В данной ветке с самого ее начала.

С самого начала ветки, как выяснилось, ты не отделял язык Дельфи от его реализации. Для тебя это суть одно и (ну судя по этой ветке) ты не видишь разницы, ну или настолько привык видеть вот так, что не замечаешь этой разницы уже.
Бога ради, вполне нормальная точка зрения, я лично ничего не имею против, но я это не сразу понял, пытаясь все трактовать с точки зрения высокоуровневого языка Delphi Language.

Но в текущую минуту мне действительно не понятно как человек, для которого указатель в языке ВУ и его реализация в виде регистра процессора в момент передачи параметра - суть одно и тоже и неотделимо одно от другого, одновременно считает кардинально разной и не эквивалентной записью числа Пи в виде вот этого Пи, и его представления в виде бесконечного десятичного представления. Да и вообще говорит (ну или подразумевает) про бесконечную по размеру запись этого числа (т.е. чистейшей воды абстракцию, реализовать "в натуре" которую невозможно в принципе, и я писал почему), хотя только что указатель был неотделим от регистра.

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

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

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

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

> Inovet © (15.06.12 18:53) [148]
> > Так и записать в нее - Пи
> Надо его вычислить и записать результат в строку.

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

> [150] KSergey © (15.06.12 19:16)
> То, что ни ты, ни я результат не сможем увидеть ибо смертны
> - ну извини, ты сам так поставил задачу.

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

> С самого начала ветки, как выяснилось, ты не отделял язык
> Дельфи от его реализации.

Я просто привык. В некоторых вещах асм мне ближе и проще чем дельфи или плюсы, поэтому для меня даже понятие "указатель" несколько искусственное. Есть адрес блока данных, как он представлен (значением в регистре, либо расположен на стеке/куче/статической константой наподобие KE_USER_SHARED_DATA) монопенисюально. Именно поэтому я спокойно и приводил такие примеры. Может быть я не прав с точки зрения прикладного программирования, но разницы нет абсолютно никакой.
А по поводу:

> кардинально разной и не эквивалентной записью числа Пи в
> виде вот этого Пи, и его представления

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

Да и кстати, Серег, в плане переносимости и т.п. вот посмотри плз вот такой пример: http://rouse.drkb.ru/other.php#round
В реальности размер оригинального рабочего модуля в 18 раз больше, тут только то, что разрешило начальство опубликовать.
Как видишь задача чересчур не тривиальная и решена двумя способами в виде портируемого кода и в виде кода на ассемблере, который порядочно быстрее портируемого. Как думаешь, оправдан ли ассемблерный вариант, с учетом того что данный код в боевом приложении вызывается в районе нескольких миллионов раз при изменении любого значения (происходит пересчет всех параметров) или стоило остановиться на том варианте, который на строках?

Вот еще.
Я просил привести примеры чисел, которые нельзя записать.

Были приведены примеры:
1) 10000000000000000000000000000000^100000000000000000000000000000000000000
2) PI

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

> KSergey © (15.06.12 21:00) [154]
> Вот еще.

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

> Rouse_ © (15.06.12 19:52) [153]
> Как думаешь, оправдан ли ассемблерный вариант,

Да я же разве против ассемблерных вставок?? Я только за! (вру, я против, но тут вопрос поддерживаемости и квалификации требующихся сотрудников компании; но это уже совсем другая опера, разумеется; это уже к вопросу построения бизнеса относится, т.е. определяется экономической эффективностью, которую каждый добивается по-разному).

Но как только появляются ассемрлерные вставки, говорить о какой-то переносимости - в моём понимании - ну просто я даже ен понимаю как. Ибо переносимость в моём понимании - это те грабли, по которым у нас ходили при порировании базовых сетевых библиотек (на Си) под Андроид, iOS и Unix. Настолько все разное - что просто диву даешься! Понятно, что ассемблерные вставки мягко говоря непортируемы здесь в принципе.

А теперь при x64 прикорячилось - так и вовсе стало тоскливо, даже Pointer с Integer не совпадают, т.е. срочно надо менять все интерфейсы на "прослоечные" типы, тоже самое с внутренними структурами хранилищ и т.д. И это самое очевидное. Проблемы со сдвигами влево-вправо, циклическими переполнениями, на которые есть заточки, и т.п. вещи, которые мнгновенно вылезают из-за смены разрядности многих типов, причем по-разному... Как это все перетестировать - вообще не понятно.

Вот это в моем понимании - про портируемость. А про перенос проекта под новую версию того же компилятора того же производителя - ну это про другое несколько. Т.е. речь опять сугубо о терминологии )

PS
Слушайте, вы бы с машими умениями научили СигналКом подписывать документы побыстрее, а? ну или нишу их занять ) а то они по 400 мс. каждые 300 байт подписывают, сюр какой-то просто.

> KSergey © (15.06.12 21:15) [156]

Нет вопрос немного в другом, без ассемблера данную задачу у меня не получилось решить правильным образом, ибо правильный вариант слишком медлен. Т.е. либо мы получаем на выходе обработку данных с солидными тормозами, либо вот так как есть... Понятно что когда (и если) начнется переход на х64 мне придется переписать порядка 310-320 тысяч строк асм кода (примерно такой объем ядра защиты и математических модулей) но без них приложение начинает выглядеть тоскливо, ибо основной упор (по крайней мере в математике) был сделан на оптимизацию (я там и так имею просадку на разложение BCD строки, пришлось помучаться, пытаясь ускорить это дело).

> Слушайте, вы бы с машими умениями научили СигналКом подписывать
> документы побыстрее, а?

Кто-бы у нас научил неназываемую контору после заключения договора выдавать данные на след день а не через полтора месяца, после того как они друг у друга все поутверждают :)

А теперь по сути.

> Rouse_ © (15.06.12 19:24) [152]
> естественно это разные вещи, ведь в первом случае я не смогу
> получить двамиллонапервый знак после запятой. Потому что его просто нет.

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

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

В поем понимании, это будет выглядеть вот так:
S[2000001+2]
(+2 - это про то, что в десятичном представлении есть цифра 3 и точка)

Совершенно очевидно, что ничто не мешает определить такую операцию "квадратные скобки", которая будет возвращать цифру на указанной позиции в десятичном представлении числа.

Ну вот и все, задача решена на мой взгляд.
Т.е. мы смогли "получить двамиллонапервый знак после запятой" (ну я подразумеваю, что реализация в этом посте просто опущена для краткости, очевидно ведь, что ее воплощение возможно).

PS
Клянусь, это не стёб и не клоунада. Я это вижу вот так.

> Далее предлагаю облечь фразу "получить двамиллонапервый
> знак после запятой" в более конкретную синтаксическую форму.
>
>
> В поем понимании, это будет выглядеть вот так:
> S[2000001+2]
> (+2 - это про то, что в десятичном представлении есть цифра
> 3 и точка)
>
> Совершенно очевидно, что ничто не мешает определить такую
> операцию "квадратные скобки", которая будет возвращать цифру
> на указанной позиции в десятичном представлении числа.

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

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

> Rouse_ © (15.06.12 21:34) [159]
> Во, все правильно пишешь, именно про это я и вел речь, но
> нюанс, все целиком разложенное число не влезет в виртуальную
> память и если по твоему варианту я захочу получить уже не
> двумиллионный знак а двутриллионный - то будет отлуп, ибо
> либо мы держим данное число на пределе точности, ограниченной
> размерами виртуалки, либо его вообще не возможно держать
> в строке и придется держать во внешнем кэше, а это уже не строка...

Еще раз.
Внутри строка содержит строго 2 символа: PI
Ничего другого (ну помимо алгоритма получения цифры на нужном знакоместе) - не нужно.

> в строке и придется держать во внешнем кэше, а это уже не строка...

А когда операционка перекидывает содержимое переменной String в виртуальную память на диск из-за израсходования физического ОЗУ - это тоже перестает быть строкой?

> Ничего другого (ну помимо алгоритма получения цифры на нужном
> знакоместе) - не нужно.

Ну т.е. рассматривается вариант [160]?
Если да - то тут никаких возражений, все правильно...

> Rouse_ © (15.06.12 21:35) [160]
> если это учитывать и эта кастомная строка будет брать данные из кэша - то тогда у тебя все правильно.

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

> Rouse_ © (15.06.12 21:39) [162]
> Ну т.е. рассматривается вариант [160]?

Нет.
Рассматривается вариант "данные + алгоритм получения нужных (производных) данных".

> [162] Rouse_ © (15.06.12 21:39)
> Если да - то тут никаких возражений, все правильно...

А если для получения более точного значения нужно предыдущее.

Удалено модератором
Примечание: 170

> Inovet © (15.06.12 21:44) [166]
> А если для получения более точного значения нужно предыдущее.

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

> Inovet © (15.06.12 21:44) [166]
> А если для получения более точного значения нужно предыдущее.

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

> KSergey © (15.06.12 21:42) [165]
> Нет.
> Рассматривается вариант "данные + алгоритм получения нужных
> (производных) данных".

Блин, я уже сам запутался...
так я в [160] это и имел ввиду, данных (кэш) и алго для получения (кастомный вариант строки получения оных)

> [168] KSergey © (15.06.12 21:48)
> Это вопрос лишь ресурсоемкости.

Но хранить нам его негде, значит и получить произвольный после предельного не сможем. Допустим, что это единственный алгоритм.

> [172] Дмитрий С © (15.06.12 21:53)
> Неужели точности Extended, например, недостаточно для каких
> либо некосмических вычислений?

Её и для космических достаточно, речь не о достаточности.

> Дмитрий С © (15.06.12 21:53) [172]
> Неужели точности Extended, например, недостаточно для каких
> либо некосмических вычислений?

А ты скомпилируй пример, он же как раз это и показывает :)

> Rouse_ © (15.06.12 21:46) [167]
> 1. данные не хранятся в строке (собственно основной постулат данного спора)

Но почему не хранятся?? Почему там должно храниться непременно десятичное представление?? и почему тогад десятичное? а если я в одинадцатеричном виде захочу результат получать?
Там как раз хранятся данные для алгоритма, то самое PI.
Ну или 1000000^2000000

> 2. для вычисления на современном компьютере даже 1 миллиардного
> знака после запятой у числа PI потребуется пару часов...

Это не делает решение некорректным.

> Inovet © (15.06.12 21:52) [171]
> Но хранить нам его негде, значит и получить произвольный
> после предельного не сможем. Допустим, что это единственный алгоритм.

Пожалуйста, перечитайте 161, чтоли...
И укажите что жеименно нам негде хранить.

> [175] KSergey © (15.06.12 21:54)
> Почему там должно храниться непременно десятичное представление??

Да неважно, пусть хранится 256-ричное.

> Дмитрий С © (15.06.12 21:53) [172]

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

> Rouse_ © (15.06.12 21:55) [176]
> угу, пардон, я там запутался, посмотри 170

Ну на сколько я понимаю - таки консенсус )

А все чертова терминология и толкование каждого термина каждым в строго определенном смысле...

> [177] KSergey © (15.06.12 21:57)
> Пожалуйста, перечитайте 161, чтоли...
> И укажите что жеименно нам негде хранить.

Если хранить число негде, то и решения нет для случая с последовательнвм приближением.

В данном вопросе кажется да :)

ЗЫ: если что ребят пардоньте сегодня больше в споре участия принимать не буду, ибо уже голова не пашет правильно, но если что, то я готов завтра продолжить :)

> Rouse_ © (15.06.12 21:58) [179]
> Блин, опять-же пардон, пример покажет не то что точности
> не хватает, а то, что стандартные функции округления не имеют достаточной точности...

Если я правильно понял, то речь о том, чтобы суметь отличить истинное 1.9999 от неистинного, т.е. реального 2, я верно понял?
Тема сама по себе животрепещущая, мы ее более грубо решаем, хотя артефакты случаются...

> KSergey © (15.06.12 22:03) [184]
> Если я правильно понял, то речь о том, чтобы суметь отличить
> истинное 1.9999 от неистинного, т.е. реального 2, я верно
> понял?
> Тема сама по себе животрепещущая, мы ее более грубо решаем,
> хотя артефакты случаются...

Абсолютно верно, у нас просто софт завязан на сметы и там ошибка округления может влиться в очень большие убытки (утрирую конечно, но например представь произошла ошибка на 1 копейку при расчете стоимости 1 кирпича при постройке кирпичного пятиэтажного дома).
Поэтому требуется очень высокоточный алгоритм. На сайте выложен т.н. пользовательский вариант, там у меня точность до 18 знаков, в боевом же алгоритме точности до 35 знаков после запятой (кункуренты не дремлют и сайт мой знают :).

> Rouse_ © (15.06.12 22:07) [185]

По секрету: мы тоже деньги в них считаем )
И тоже округлять до копеек лишь бы как - нельзя, да )

> Тема сама по себе животрепещущая, мы ее более грубо решаем,
> хотя артефакты случаются...

Кстати, если у вас конечно не что-то секретное, не мог бы показать ваш вариант?

зы: можно в личку rouse79@yandex.ru

> Rouse_ © (15.06.12 22:15) [187]
> Кстати, если у вас конечно не что-то секретное, не мог бы показать ваш вариант?

Только тапками не кидаться )

Хранятся копейки до дробной точки. Из этого исходим.

Идея тупая и очень грубая дальше: делим/умножаем, когда закончили - то прибавляется 0,5+EPS (EPS что-то тпа 0,00001) - и отрубаем дробную часть. Я понимаю, что при этом может получиться все те же 1,9999 вместо истинной двойки, но тут уже вопрос интерпретации в момент печати, просто алгоритмы отображения устроены как-то так, что рисуется 2 в таком случае.

Выбор EPS строится из такой эмпирики: есть разумное количество копеек во вселенной, и есть еще более разумное количество, с которым некий реальный субьект может оперировать.
Соответствено EPS должно быть такое, чтобы при максимальном количестве копеек эта единичка в EPS не вывалилась за размер мантиссы.
Собственно спец эффекты возникают лишь тогда, когда "более разумное количество" постепенно меняется на порядки ввиду инфляции.

Это явно много грубее вашего подхода, но если исходить из того, что это вот копейки и нам надо до копеек округлить - то я не вижу разницы между истинным 1,9999 и истинным 1,9997. Лишь бы единичка наша не попала на 7, нехорошо получится )

Вспомнилось из математики.
Почему 0.9999(9) = 1 ?

нашел
http://ru.wikipedia.org/wiki/0,%289%29

странно, нам это объяснили тем, что 0.9999(9) = 1 по определению равенства, т.к. между ними нельзя вставить какое либо действительное число (0.9999(9) < x < 1)

> то прибавляется 0,5+EPS (EPS что-то тпа 0,00001)

Угу знакомо, мы попадали на такое, собственно исходя из примерно похожего примера и было принято решение писать туеву хучу высокоточных алгоритмов.
А кратце попадалово было в тот момент, когда число (допустим) было 1.99994 (абсолютно нормальный результат без погрешности в последней четверке) и тут мы правим "погрешность" прибавляя этот 0,00001 (в оригинале было 0,00000001), получая на выходе двойку на округлении.
Газпром был очень не доволен (мягко говоря) :)
Пришлось проштудировать много макулатуры по представлению чисел в матсопроцессоре, найти там ошибку (багрепорт ушел в интел), потом сделать то-же самое по процессорам от АМД, вычислить лимит погрешности для обоих железяк, рассчитать сальдо на пике (мы остановились на 96, т.е. 4 процента ошибок при 35 знаках пос запятой, что за глаза) и по минимуму доводить исходный матаппарат под результат, ибо там если немного перекрутить - то сыпятся ошибки но уже с другой стороны (ну что-то типа переполнения, но по другому)

> Пришлось проштудировать много макулатуры по представлению
> чисел в матсопроцессоре, найти там ошибку

А если не сложно можно маленький пример воспроизводящий ошибку?

> А если не сложно можно маленький пример воспроизводящий
> ошибку?

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

> Там ошибка в документации, ес не ошибаюсь один из регистров
> не инициализировался так как было описано в документации,
> или наоборот.

У обоих производителей?

А на практике в чем ошибка выражалась?

А по поводу АМД, из-за него идет ветвление выходящее на "fprem1". Точнее как потом показала практика под i5/i7 тоже туда происходит выход в отличие от предыдущих моделей...

> У обоих производителей?

Нет.

> А на практике в чем ошибка выражалась?

Я использовал регистр, который изменялся в результате выполнения другой инструкции. В документации на тот момент такой нюанс отображен не был. Грубо для воспроизведения необходимо вызвать функцию разложения числа в BCD строку, причем число должно быть в определенном диапазоне...

Давно не встречалось на дм чего нить интересного почитать. Спасибо.

зы, ну я в смысле что народ давно погряз в оффтопах и даже не ожидал что в споре родится техническая ветка :)

> Rouse_ © (15.06.12 23:36) [200]
>
> зы, ну я в смысле что народ давно погряз в оффтопах и даже
> не ожидал что в споре родится техническая ветка

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

> turbouser © (16.06.12 01:51) [202]
>
>
> > Германн © (16.06.12 01:06) [201]
>
> Обычно такого рода обсуждения велись в основном в чате.
>

В каком чате? На ДМ? А разве он функционирует?

> Rouse_ (15.06.2012 23:36:20) [200]

Главное было ее не приглушать (moderato)

Ассемблерные вставки и переносимость кода Найти похожие ветки