Как-то нет уверенности, что код необходимый для буферизации обязательно имет count>1

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

Так я и говорю - не факт что достаточно...
Ну вернет кто-то на нижнюю точку:
и что тогда? Какой же это LValue

Или наоборот, приспичит (когда-нибудь) добавить какой-нибудь префикс видимости для буферизированной переменной...

Да, конечно же опять : не стоит у меня задачи вот именно сейчас куда-то что-то написать.
Нет такого: "...ну очень нужно. Вопрос жизни и смерти"

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

Непонял при чем тут LValue?

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

видимо про разные вещи говорим. Я имел ввиду, что после получения данных, например, хабом вот в этих двух случаях:
1) [переменная] - str23
2) [выражение] - str23 str56

достаточно проверять количество элементов ка кпризнак присутствия выражения:

как-то примерно так. LValue тут вроде бы и ни при делах.

1) Dilma, ты придумай чего-нибудь, чтобы твои посты парсились правильно и в ЭТОМ форуме (в новом - парсятся правильно)
Потому что на новый переходить еще рановато: не все там сделано для удобства еще
Мне-то - ладно: редактировать+сохранить -> и все нормально

А другие и не сразу въехать могут
Особенно если это в кодах...


2) Так я вроде так и понял...
Да, в простейших случаях это работает.
Но бог с ними с простейшими случаями. Хочется ведь работать один раз, чтобы про этот мелкий казус забыть на всю оставшуюся жизнь.
[size=-2]btw: ((о причинах этого "хочется" можно говорить по разному: а) просто ленивый я, чтобы потом снова возвращаться в пройденному б) спешить надо не торопясь в) у нас мало интеллектуальных ресурсов, чтобы позволять себе разрабатывать один вопрос в нескольких версиях - лучше сразу в финальной г) не планируй себе проблемы "на потом" - они и без нашего спроса возникнут, в очень достаточном количестве))

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

про LValue продолжаю не понимать.


ошибка разработчика элемента.


момент спорный. Сильно зависит от компилятора. Скажем есть код:
скажем нормальный компилятор один раз загрузит в регистр адрес obj.field и подставит в оба выражения. Т.е. он превратит код в такое:
что от проделываемой нами буферизации не отличается. Зато код становится более читабельным.

Для меня LValue это каким-то языковым образом представленный адрес памяти, где находятся данные. Именно уже посчитанные - иначе в случае LValue и быть не может.
Если это LValue, то никто не обязывает меня туда именно писать, хотя и разрешает.
Читать тоже разрешает.
А RValue, это выражение, посчитанное или нет - бабка надвое сказала
Настолько "надвое", что, как мне кажется - Count не будет работать 100%-но

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


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


Ну, во-первых, я имел в виду статические элементы.
В этом случае любой длины "обточивание" разрешимо в Design-Time.
Даже в Fasm, без применения дополнительных интеллектов - это элементарно (хотя исключать глупостей и самых продвинутых компиляторов - нельзя).
Для динамических, кстати, в CPP была бы другая запись 'SDK_0->SDK_15->'

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

Именно этот пользователь (1-го уровня) для случая 'Applet.width*3/2' должен каким-то образом сообщить CG "потенциально нуждается"
А для случая return(d && '.data1.RefCount') сообщить "не нуждается", или наоборот - именно исходя из знаний языка, и особенностей компилятора.
И никаких спорных моментов.
Пользователь (1-го уровня) сам с собой поспорил, почитал буквари, и принял решение.
И все споры закончились - так должно быть, мне кажется.

А наша задача - дать ему физическую возможность "принять это решение", а не принимать за него.
Собственно, частично уже дали: ведь именно Пользователь 1-го уровня написал шаблон буферизации в direct.inc.
И именно он (в том смысле, что уж точно - не CG) отвечает за то, что после применения этого шаблона - флаг категорически устанавливается в "не нуждается"
Чистый LValue, между прочим....

---

Мысль-то основная в том, что использование Count вместо такого св-ва - не шибко-то и надежно.
Или по-другому: есть сомнения в достаточности условия Count(_data)>1
Мне понятно, что было бы удачно, если бы у нас такое уже мимоходом было бы.
Но не совсем так это... Разные немного вещи это....

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

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

да наврено должен, но получается в итоге, что мы вводим некое новое понятие "Буферизируемость выражения", которого нет ни в одном нормальном языке. А нет его потому, что там этим компилятор занимается. И если спросить меня, что я выберу: качество кода или доступность языка - я выберу второе. Если при написание элемента застолбить общее правило о том, чтобы в код не печатали сложных комбинаций типа:
то никаких напрягов у пользователя это не вызовет - писать операторы отдельно это понятно, логично и легко усваемого. Ну положим в каком-то из ряда вон выходящем случае буферизируем мы [b]return(d

как сообщения лихо режит

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

поэтому на данный омент в WEB видится решение:
для типозависимых языков буфер еще объявляется с типом из subtype

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

Но все-таки, давай посмотрим:
1) В любом нормальном языке существует понятие LValue, невзирая на понимание и отношение к этому понятию вышеупомянутых коллег
Здесь что-то похожее, возможно, хотя мы это как-то по-другому называем (вообще-то, я настаивал на достаточности именно LValue )
Да и с понятностью там, в прославленных языках, тоже не все так просто. И никто не застрелился от этого.
Напомню, что такое в Дельфях просто не компилится:
- и понимай как хочешь :lol:
2) Вот я интересуюсь: в кодах StrCat есть такое
- так какой там Count все-таки, и нуждается ли сей код в буферизации, если там просто две "константы" получаются.
3) Насчет выбора: а он разве есть?
Альтернативой являются не до конца решенные вопросы. Или их решение за счет качества.
Конечно, если в моих рассуждениях нет логической ошибки.
Мне кажется, что неким "запретом" для пользователя мы проблемы не закроем, а создадим.
Это закон природы, проверенный на практике: как только мы начинаем "перегружать функциональность", то начинается тришкин кафтан. В одном месте чего-то отыграешь - в другом месте стрельнет...и хуже всего, что стреляет не сразу, а потом - когда все успокоятся

Типа: работает аж на целых 99%.
По разному можно относиться к "допустимости" такого...
По мне так: "...осетрины второй свежести не бывает"
Такую "осетрину" я в любом компиляторе посмотреть могу: хоть в FPC, хоть в GCC...

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

---

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

Если у меня есть (предположим) знания о том, как надо строить код, то у меня должны быть (в перспективе хотя бы) возможности воплотить эти знания.
Предположим, что некий "запрет", или "правило" дает такую возможность
Так во-первых: сомневаюсь, что дает.
Во-вторых: совсем уж сомневаюсь, что это будет понятней, чем LValue.

Ну второе - это стилистические вещи, хотя по моему опыту, именно стилистика шанхаев (использовать имеющееся) и приводит к опасным не устойчивостям проектов

А вот первое - принципиально. При таких сомнениях спокойно работать - ну никак нельзя.

Давай уточним:
У меня нет никаких сомнений, что Count(_data_)>1 является достаточным условием для НЕ буферизации после уже проведенной буферизации. Мы так написали шаблон: именно с Count=1
Мне понятно также, что:
1) Мы таки можем гарантировать специальным "правилом" для Пользователя-1, что код, сразу нуждающийся в буферизации, будет иметь Count>1

Но вопрос ведь не только в этом - он пошире будет. А именно:
2) Где гарантии, что код (сгенерированный где угодно, а не только по нашему шаблону) не нуждающийся в буферизации, будет всегда обладать Count=1
3) Где гарантии, что код, не нуждающийся в буферизации, никогда не подвергнется модификациям, не меняющим его атрибут LValue, но меняющим его Count.

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

По второму пункту - да посмотрим на любой "конструктор кодов" из CG
Чуть что - так в массив его.
Но далеко не всякое "чуть что" ухудшает код.
Не много у нас сегодня кодов, но в StrCat вот это
То самое небольшое "чуть что" Опять получается - нет гарантий

А если нет гарантий по этим 2-м пунктам, следовательно, существуют оптимизационные процедуры, совершенно очевидные для человека, но которых мы никогда не достигнем В ПРИНЦИПЕ.

И причина этому: даже не наше непонимание вопроса ( ), а некая мифическая не понимаемость чего-то кем-то
Такой логики я просто не в состоянии понять...

[size=-2]------ Добавлено в 17:44

Ну-ну

Кстати, о какой простоте идет речь

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

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

Galkov
- тоже понимает, что хорошо и что плохо
- не желает делать ничего такого, что заведомо можно сделать лучше
- качество кода ухудшать не желает ни на йоту даже если это приведет к усложнению синтаксиса скрипта


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

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

Galkov, Dilma,
А непроще ли вам общяться по Skype.
Удобнее и продуктивнее.

Форум тем и хорош, что всегда можно ссылку дать в нужное место.