Dilma писал(а):
то никаких напрягов у пользователя это не вызовет А вот в этом как раз и сомнения
Тут конечно плохо, что оперируем еще "не написанной буферизацией". Длинная цепочка логических рассуждений получается - возможны и ошибки.
Но все-таки, давай посмотрим:
1) В любом нормальном языке существует понятие LValue, невзирая на понимание и отношение к этому понятию вышеупомянутых коллег
Здесь что-то похожее, возможно, хотя мы это как-то по-другому называем (вообще-то, я настаивал на достаточности именно LValue )
Да и с понятностью там, в прославленных языках, тоже не все так просто. И никто не застрелился от этого.
Напомню, что такое в Дельфях просто не компилится:
List.Items[0][1] := 'S';
2) Вот я интересуюсь: в кодах StrCat есть такое
return(Str1 & Str2)
3) Насчет выбора: а он разве есть?
Альтернативой являются не до конца решенные вопросы. Или их решение за счет качества.
Конечно, если в моих рассуждениях нет логической ошибки.
Мне кажется, что неким "запретом" для пользователя мы проблемы не закроем, а создадим.
Это закон природы, проверенный на практике: как только мы начинаем "перегружать функциональность", то начинается тришкин кафтан. В одном месте чего-то отыграешь - в другом месте стрельнет...и хуже всего, что стреляет не сразу, а потом - когда все успокоятся
Типа: работает аж на целых 99%.
По разному можно относиться к "допустимости" такого...
По мне так: "...осетрины второй свежести не бывает"
Такую "осетрину" я в любом компиляторе посмотреть могу: хоть в FPC, хоть в GCC...
Но опять же повторюсь (чтобы пятый раз не наступить на те же грабли) нет у меня претензий, что надо все сделать сегодня и сразу.
Но вот понимание того, что рано или поздно к этому придем - иметь хотелось бы...
Dilma писал(а):
но получается в итоге, что мы вводим некое новое понятие "Буферизируемость выражения" Вообще-то введение какого-то понятия не являлось моей целью.
Я хочу получить понимание возможных путей решения проблемы БЕЗ скидок на "понимаемость"
Вообще без скидок.
С радостью буду обсуждать любое предложение. Если "без скидок"
Если у меня есть (предположим) знания о том, как надо строить код, то у меня должны быть (в перспективе хотя бы) возможности воплотить эти знания.
Предположим, что некий "запрет", или "правило" дает такую возможность
Так во-первых: сомневаюсь, что дает.
Во-вторых: совсем уж сомневаюсь, что это будет понятней, чем LValue.
Ну второе - это стилистические вещи, хотя по моему опыту, именно стилистика шанхаев (использовать имеющееся) и приводит к опасным не устойчивостям проектов
А вот первое - принципиально. При таких сомнениях спокойно работать - ну никак нельзя.
Давай уточним:
У меня нет никаких сомнений, что Count(_data_)>1 является достаточным условием для НЕ буферизации после уже проведенной буферизации. Мы так написали шаблон: именно с Count=1
Мне понятно также, что:
1) Мы таки можем гарантировать специальным "правилом" для Пользователя-1, что код, сразу нуждающийся в буферизации, будет иметь Count>1
Но вопрос ведь не только в этом - он пошире будет. А именно:
2) Где гарантии, что код (сгенерированный где угодно, а не только по нашему шаблону) не нуждающийся в буферизации, будет всегда обладать Count=1
3) Где гарантии, что код, не нуждающийся в буферизации, никогда не подвергнется модификациям, не меняющим его атрибут LValue, но меняющим его Count.
По первому пункту - ну вот привел пример про константы в StrCat...
И еще можно придумать наверняка - таково уж св-во тришкиного кафтана...
И никак этот вопрос вышеозначенное правило не затрагивает
Нет у нас гарантий по этому пункту, получается.
По второму пункту - да посмотрим на любой "конструктор кодов" из CG
Чуть что - так в массив его.
Но далеко не всякое "чуть что" ухудшает код.
Не много у нас сегодня кодов, но в StrCat вот это
return(Str1 & Str2)
А если нет гарантий по этим 2-м пунктам, следовательно, существуют оптимизационные процедуры, совершенно очевидные для человека, но которых мы никогда не достигнем В ПРИНЦИПЕ.
И причина этому: даже не наше непонимание вопроса ( ), а некая мифическая не понимаемость чего-то кем-то
Такой логики я просто не в состоянии понять...
[size=-2]------ Добавлено в 17:44
Dilma писал(а):
за ухудшение качества кода взамен этой простотыНу-ну
Кстати, о какой простоте идет речь
Позволю себе заметить, что ровно в тот момент, как произносятся слова "ухудшение качества кода" - проект можно заканчивать.