Вверх ↑
Ответов: 9906
Рейтинг: 351
#1: 2007-07-17 17:44:29 ЛС | профиль | цитата
Dilma писал(а):
то никаких напрягов у пользователя это не вызовет

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

Но все-таки, давай посмотрим:
1) В любом нормальном языке существует понятие LValue, невзирая на понимание и отношение к этому понятию вышеупомянутых коллег
Здесь что-то похожее, возможно, хотя мы это как-то по-другому называем (вообще-то, я настаивал на достаточности именно LValue )
Да и с понятностью там, в прославленных языках, тоже не все так просто. И никто не застрелился от этого.
Напомню, что такое в Дельфях просто не компилится:
 List.Items[0][1] := 'S';
- и понимай как хочешь :lol:
2) Вот я интересуюсь: в кодах StrCat есть такое
    return(Str1 & Str2)
- так какой там Count все-таки, и нуждается ли сей код в буферизации, если там просто две "константы" получаются.
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 писал(а):
за ухудшение качества кода взамен этой простоты

Ну-ну

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

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

0