Автор Тема: Приспособим PureBuilder для разработки игр  (Прочитано 42292 раз)

Berserker

  • Sr. Member
  • ****
  • Сообщений: 254
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #30 : Февраль 17, 2011, 08:30:49 pm »
Javascript - Number.

Comdiv

  • Newbie
  • *
  • Сообщений: 25
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #31 : Февраль 20, 2011, 11:38:28 am »
Да, это интереснее :) ...
Напишите, пожалуйста, весь код. А заодно опишите, какими свойствами должен обладать язык, чтобы делать такие штуки было удобно. И как Вы считаете, можно ли считать это правило маленькой добавкой в язык уровня Оберон (когда-то Вы писали, что оно легко и элегантно впишется в его гипотетический диалект).

Также подумайте, чего этот способ делает больше: решения проблем или их создания (просто подумайте, отвечать не надо, поскольку Ваш ответ и так очевиден с вероятностью 87.34%).

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #32 : Февраль 21, 2011, 03:01:03 pm »
Напишите, пожалуйста, весь код.

C расчетом, что у нас в языке а-ля оберон с сишным синтаксисом есть туплы (если нет, то всегда можно отбиться структурами/записями):
(Type t1, TypeOptional t2)
f() {
    if (c1) {
        Type t3 = f0(p1, p2);    
         return f1(p1, t3), f2(p2, t3);
    } else {
        return t1, null;
    }
}
...

Type t1, TypeOptional t2 = f();
...
if (optional_cast<Type>(t2) && c2) {
   f5(t1);
   f6(t2); // здесь t2 гарантировано не "пустое", компилятор про это знает, потому что выше произошла проверка/приведение типа от TypeOptional к Type
} else {
   f7(t1);
}

Цитата: Comdiv
А заодно опишите, какими свойствами должен обладать язык, чтобы делать такие штуки было удобно. И как Вы считаете, можно ли считать это правило маленькой добавкой в язык уровня Оберон (когда-то Вы писали, что оно легко и элегантно впишется в его гипотетический диалект).

Если в порядке "величины" добавки, то от языка нужны следующие свойства:
1. Механизм исключений в каком-то виде. Если инициализировать при объявлении, то код ошибки обрабатывать уже негде. Да, это совсем немаленькая добавка, но зато хорошо изученная и без нее жить трудно безотносительно к предлагаемым изменениям.
2. Объявление локальных переменных по месту (упразднение отдельной секции VAR). Тоже повсеместно доказанное благо, хотя убежденные паскалисты держатся за нее до конца :)
3. Добавление null'able в систему типов. Существующих примеров много, начиная с SQL и заканчивая C#, ничего нового, все известно и понятно.
4. Тернарный оператор и туплы. Можно и без них (особенно без туплов), но с ними приятнее :)

Цитата: Comdiv
Также подумайте, чего этот способ делает больше: решения проблем или их создания (просто подумайте, отвечать не надо, поскольку Ваш ответ и так очевиден с вероятностью 87.34%).

Я пока не нашел каких-то проблем/противоречий, к которым могут привести предлагаемые изменения. Изменений в компиляторе относительно немного. Язык станет более выразительным (за счет расширения системы типов) и сменится стиль написания кода в сторону более гранулярной декомпозиции (как в данном примере).
« Последнее редактирование: Февраль 21, 2011, 03:13:02 pm от valexey »

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #33 : Февраль 21, 2011, 03:15:55 pm »
Поправил оформление цитат в сообщении vlad'a. (добавил закрывающий тэг [/quote]).
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Comdiv

  • Newbie
  • *
  • Сообщений: 25
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #34 : Февраль 22, 2011, 06:50:42 pm »
C расчетом, что у нас в языке а-ля оберон с сишным синтаксисом есть туплы (если нет, то всегда можно отбиться структурами/записями):
С учётом того, что это должно быть удобным (иначе кто так будет писать?), то либо кортежи обязательны, либо структуры должны быть существенно переработаны.
Я просил привести весь код, но создаётся впечатление, что многое всё же недосказано. Что такое TypeOptional - фишка языка, позволяющая прилепливать к типу слово Optional, после чего получаем особый тип? Или он всё же где-то объявлен, тогда где его код?

1. Механизм исключений в каком-то виде. Если инициализировать при объявлении, то код ошибки обрабатывать уже негде. Да, это совсем немаленькая добавка, но зато хорошо изученная и без нее жить трудно безотносительно к предлагаемым изменениям.
2. Объявление локальных переменных по месту (упразднение отдельной секции VAR). Тоже повсеместно доказанное благо, хотя убежденные паскалисты держатся за нее до конца :)
3. Добавление null'able в систему типов. Существующих примеров много, начиная с SQL и заканчивая C#, ничего нового, все известно и понятно.
4. Тернарный оператор и туплы. Можно и без них (особенно без туплов), но с ними приятнее :)

Лихо Вы объединили тернарный оператор и кортежи в один пункт, полагаю, что 2-е намного сложнее 1-го. Также думаю, что без них нельзя, иначе фишка будет не удобной.

Полагаю, что кое-что забыто (я не прогонял это тщательно в уме):
Отказ от статических структур и от структур как таковых, одни объекты, либо добавление хитрых механизмов для работы с ними.
Добавление конструкторов, да не простых, а с инициализацией всех данных объекта.
Объявление данных модуля с инициализацией.
Отказ от данных модуля, которые  не могут быть инициализированы по месту.
Как-то придумать инциализацию по месту массивов, или отказ от них.
Отказ от 1-го RETURN (Оберон ведь движется в этом направлении)
В Вашем примере, не шаблоны ли использованы для приведения типа?
Возможно, что-то ещё.

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

По-моему вырисовывается не диалект Оберона, а совсем другой язык.

Цитата: Comdiv
Также подумайте, чего этот способ делает больше: решения проблем или их создания (просто подумайте, отвечать не надо, поскольку Ваш ответ и так очевиден с вероятностью 87.34%).

Я пока не нашел каких-то проблем/противоречий, к которым могут привести предлагаемые изменения. Изменений в компиляторе относительно немного.
Предложу свои варианты ответов:
1.При необходимости многие будут не выкручиваться в эквивалентные преобразование кода, а инициализировать по месту мусорно, что затруднит обнаружение ошибки, в случае если переменная так и не будет проинициализирована нормально (за что боролись, на то и напоролись).
2.Усложнение языка и компилятора, ради небольшой проблемы. Ведь изначально шла речь о простом изменении, существенно более простом, чем то, что реализовано в анализаторе BlackBox или компиляторе java. А если нам нужен другой язык, с кортежами, исключениями, nullable типами и другими фишками, это другой вопрос.
3.Возможно, что-то ещё. Мне не так-то просто предвидеть все последствия от необходимых изменений.
« Последнее редактирование: Февраль 22, 2011, 06:59:27 pm от Comdiv »

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #35 : Февраль 22, 2011, 07:28:56 pm »
С учётом того, что это должно быть удобным (иначе кто так будет писать?), то либо кортежи обязательны, либо структуры должны быть существенно переработаны.

С рекордами можно жить (я в С++ живу, хотя там есть boost::tuple). Писанины чуть больше, зато поля именованы, зачастую это повышает читабельность. Существенной переработки применительно к оберону не надо, достаточно иметь синтаксис для инициализации рекордов (так же как и массивов). Этот недостающий сахар уже обсуждали - без него неудобно и в классическом обероне.

Цитата: Comdiv
Я просил привести весь код, но создаётся впечатление, что многое всё же недосказано.

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

Цитата: Comdiv
Что такое TypeOptional - фишка языка, позволяющая прилепливать к типу слово Optional, после чего получаем особый тип? Или он всё же где-то объявлен, тогда где его код?

Это что-то типа:
TYPE TypeOptional = OPTIONAL INTEGER;
или
typedef optional int TypeOptional;

Цитата: Comdiv
Лихо Вы объединили тернарный оператор и кортежи в один пункт,

Оно не принципиально :) Хотя тернарный оператор все же нужнее.

Цитата: Comdiv
полагаю, что 2-е намного сложнее 1-го. Также думаю, что без них нельзя, иначе фишка будет не удобной.

Чего ж там сложного??? Компилятор уже умеет иметь дело с временными переменными (для вычисления выражений). Объявление по месту - такая же временная переменная.

Цитата: Comdiv
Полагаю, что кое-что забыто (я не прогонял это тщательно в уме):
Отказ от статических структур и от структур как таковых, одни объекты, либо добавление хитрых механизмов для работы с ними.

Не, не понял. Что такое статические структуры?

Цитата: Comdiv
Добавление конструкторов, да не простых, а с инициализацией всех данных объекта.

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

Цитата: Comdiv
Объявление данных модуля с инициализацией.
Отказ от данных модуля, которые  не могут быть инициализированы по месту.

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

Цитата: Comdiv
Как-то придумать инциализацию по месту массивов, или отказ от них.

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

Цитата: Comdiv
Отказ от 1-го RETURN (Оберон ведь движется в этом направлении)

А может это неправильное направление? :)

Цитата: Comdiv
Возможно, что-то ещё.

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

Потому что результат будет "мусорным" в случае ошибки. А мы не хотим мусорных значений.

Цитата: Comdiv
По-моему вырисовывается не диалект Оберона, а совсем другой язык.

Да ладно. До какого-нибудь С++ или жабы такому диалекту очень далеко :) А определенные проблемы решаются.

Цитата: Comdiv
Предложу свои варианты ответов:
1.При необходимости многие будут не выкручиваться в эквивалентные преобразование кода, а инициализировать по месту мусорно, что затруднит обнаружение ошибки, в случае если переменная так и не будет проинициализирована нормально (за что боролись, на то и напоролись).

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

Цитата: Comdiv
2.Усложнение языка и компилятора, ради небольшой проблемы. Ведь изначально шла речь о простом изменении, существенно более простом, чем то, что реализовано в анализаторе BlackBox или компиляторе java. А если нам нужен другой язык, с кортежами, исключениями, nullable типами и другими фишками, это другой вопрос.

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

Цитата: Comdiv
3.Возможно, что-то ещё. Мне не так-то просто предвидеть все последствия от необходимых изменений.

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

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #36 : Февраль 22, 2011, 08:33:50 pm »
В LLVM кортэжи есть сразу. Вообще кортэж, для компилятора, и вообще на низком уровне штука весьма простая и ничем принципиально от тех же структур не отличается.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Валерий Лаптев

  • Jr. Member
  • **
  • Сообщений: 58
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #37 : Февраль 23, 2011, 05:55:54 am »
Вставлю свои 5 копеек:
1. Инициализацию модульных переменных можно делать в секции инициализации модуля - я правильно понимаю? Придумывать для этого специальный синтаксис - не обязательно.  Хотя, конечно, можно это повесить на компилятор - пусть из инициализатора сделает преобразование в секции инициализации модуля.
2. Объявление по месту - мне нравится.
3. Объявление с инициализацией - ИМХО только для встроенных типов. Тем более, что это опять можно повесить на компилятор - пусть разнесет объявление и инициализацию.

Соответственно 4 - никаких конструкторов! Или надо МНОГО думать, как их ограничить. В С++ конструкторы вызываются по умолчанию, что есть зло. Единственное ограничение, которое программер может употребить - это explicit. Но не обязательно, поэтому мало кто пишет, особенно начинающие.
Соответственно 5 - нет необходимости в механизме исключений.

Сергей Прохоренко

  • Newbie
  • *
  • Сообщений: 16
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #38 : Февраль 23, 2011, 10:47:18 am »
Соответственно 5 - нет необходимости в механизме исключений.

Вы теперь против механизма исключений, даже такого сильно ограниченного функциональным стилем и "скрещенного" с кодами ошибки, как в PureBuilder?

Возникает несколько вопросов:
1) Что взамен - для действительно аварийных ситуаций, делающих бессмысленным возвращаемое значение функции?
2) Что изменить в языке, чтобы код обработки ошибок в рантайме был отделен в программе от нормального штатного кода?
3) Как же тогда учить студентов осторожному применению механизма исключений в "промышленных" языках?

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #39 : Февраль 23, 2011, 01:47:10 pm »
Вставлю свои 5 копеек:
1. Инициализацию модульных переменных можно делать в секции инициализации модуля - я правильно понимаю? Придумывать для этого специальный синтаксис - не обязательно.  Хотя, конечно, можно это повесить на компилятор - пусть из инициализатора сделает преобразование в секции инициализации модуля.

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

Цитата: Валерий Лаптев
2. Объявление по месту - мне нравится.
3. Объявление с инициализацией - ИМХО только для встроенных типов. Тем более, что это опять можно повесить на компилятор - пусть разнесет объявление и инициализацию.

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

Цитата: Валерий Лаптев
Соответственно 4 - никаких конструкторов!

Да, конструкторы не нужны. Достаточно синтаксиса инициализации полей записи и элементов массива. Для массивов неизвестной длины - значение по умолчанию.

Цитата: Валерий Лаптев
Соответственно 5 - нет необходимости в механизме исключений.

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

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #40 : Февраль 23, 2011, 03:34:37 pm »
Про инициализацию массивов... Что мешает сделать ленивую инициализацию? Т.е. инициализация данной ячейки массива непосредственно ПЕРЕД чтением. Если данную ячейку вначале не читают, а скажем сразу туда пишут, то оверхеда не будет вообще.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #41 : Февраль 23, 2011, 06:32:34 pm »
Ответ на оригинальный пост в http://forum.oberoncore.ru/viewtopic.php?p=60599#p60599

Цитата: Илья Ермаков
Цитата: Сергей Прохоренко
foreach'и бывают разными. Может быть, Вы имели дело с неудачными, и надо сделать (или позаимствовать) другой вариант? Например, с не столь безальтернативной "отначаладоконцовостью"?
Так это будет WHILE и райдер, как раз.

foreach - это райдер-итератор, спаянный намертво с циклом, при этом с циклом, который идёт от начала до конца.
Максимально специализированная вещь. Если, конечно, не разрешать "стоп-кран" break и "прыжки из поезда на ходу".

Максимально специализированная вещь - это как раз очень хорошо. Особенно, если она максимально специализирована для 90% случаев использования в конкретном проекте :)
foreach дает возможность максимально удобно обработать значения элементов последовательности. И больше ничего. Причем его основное достоинство именно в этом "ничего", а не в краткости записи :) Он не даст вам неправильно выбрать следующий элемент, он не даст вам изменить значение этого элемента, он не даст вам неправильно прописать условие завершение цикла. Он не даст вам совершить кучу ошибок. А в качестве бонуса - читающий ваш код сразу увидит, что вы не делаете здесь ничего неожиданного (см. список чего foreach "не даст") - и спокойно пойдет читать дальше более интересные вещи.

Berserker

  • Sr. Member
  • ****
  • Сообщений: 254
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #42 : Февраль 23, 2011, 06:43:17 pm »
Как всё сложно.

Цитировать
[17.1] What are some ways try / catch / throw can improve software quality?

FAQ: You'll have less if statements in your code: you won't have to check for errors each time you call a function. Conditional statements are known to contain more bugs than other statements. With less if tests, you'll ship a better product, faster.

FQA: This is cargo cult programming. Conditional statements are error-prone because they are used to handle complicated scenarios, where an action can result in many different outcomes, which affect the next actions. In order to make errors less probable, one has to simplify the model of the desired behavior of the software. The problem is the complexity that leads to if statements, not the if keyword, and using different keywords is not going to solve the problem by itself.

Exceptions are supposed to simplify the error handling model based on the assumption that in most cases, a function that detected an error can't handle it, and has to propagate it to the caller. Finally, a "high-level" enough caller is reached and actually makes a decision (pops up an error message, tries a different action, etc.).

Despite its promises, this approach has inherent problems. There's a "social" problem - with exceptions, people are not aware of the different errors that may happen in the code because most of the code doesn't deal with errors. And when people rarely think about a particular aspect of an application, ultimately this aspect is unlikely to be handled well. There's a more "technical" problem - functions essentially doing nothing upon error except for propagating errors to the caller still can't be completely unaware of errors. That's because they may need to release the resources they acquired before returning to the caller, which may lead to more errors, which must also be handled. Finally, in practice exception support has run-time overhead, and very significant code size overhead, even if exceptions are never raised at run time, and even if they are not mentioned in your code. C++ devotees may claim otherwise; you can check by compiling your code with and without exception support (if your compiler doesn't have such a flag, compile code as C and as C++ instead). This is unacceptable in resource-constrained systems.
Отрицательный результат - тоже результат. И хотя нас часто порывает принять за данность выполнение программы в идеальном окружении с идеальным пользователем, а всю логику обработки ошибок закинуть как можно выше, это не выход. Пора уже понять, что практически все функции не способны гарантировать результат. Что исключения одного класса обезличиваются при всплывании, превращаясь в нечто вроде TIOError. Что если мы хотим обработать 250 вызовов функций по-разному, нам понадобятся 250 обработчиков и их логика должна быть на том же уровне, что и вызов функций.

Посмотрите на самые азы - арифметику. +, -, * - возможность выхода за границы типа (переполнение), / - тоже + деление на 0. Практически каждая функция из rtl в php может вернуть ошибку. Работа со строками, массивами, форматами - чем угодно. Если возвращаемое значение функции и есть её результат, то механизм исключений будет использоваться всегда. Или же его тросянка. Часть функций с кодами ошибок, другая на исключениях. Вопрос. А что есть исключение? То, что сейчас модно называть исключением, является ничем иным как штатной ситуацией. Зачем вводить исключения, потом для них же магические способы финализации, затем перегрузку операторов, которая без исключений вообще нежизнеспособна. Затем возвращение сложных структур функциями. Что более фундаментально? Что автономно? Что проще в реализации? С какой кстати высший уровень должен знать все типы исключений низших, а если не знать, то иметь лишь единственный молчаливый способ их обработать? Наконец, зачем ещё один goto на адрес в стёковой структуре, когда стремимся к безопасному, надёжному и наглядному коду, где прыжкам в неизвестность просто не место.

P.S Кстати, пример изначально неверного подхода к проектированию можно увидеть в обероновском модуле Files. Там функции работают с идеальной файловой системой и понятия ошибки нет вообще.

Заключение: для действительно исключительных ситуаций (определённого класса) достаточно функций-финализаторов.

Comdiv

  • Newbie
  • *
  • Сообщений: 25
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #43 : Февраль 23, 2011, 06:59:10 pm »
Цитата: vlad
С рекордами можно жить (я в С++ живу, хотя там есть boost::tuple). Писанины чуть больше, зато поля именованы, зачастую это повышает читабельность. Существенной переработки применительно к оберону не надо, достаточно иметь синтаксис для инициализации рекордов (так же как и массивов). Этот недостающий сахар уже обсуждали - без него неудобно и в классическом обероне.
1.Необходимость больше писать приведёт к тому, что фишкой не будут пользоваться. Перепишите пример со структурами и сравните. Вспомните хотя бы, как сишники жалуются на "многословность" синтаксиса Оберона. 2.Как минимум нужно и объявление типа по месту.

Цитировать
Чего ж там сложного??? Компилятор уже умеет иметь дело с временными переменными (для вычисления выражений). Объявление по месту - такая же временная переменная.
Не знаю, не пробовал реализовать, но интуитивно чувствую, что не очень это просто для понимания компилятора, когда группу чего-то отдельного, можно представить как одно и наоборот. Тернарный оператор намного проще, особенно если не как в С, а как-то так :
Цитировать
TOP(condition, value1, value2);

Цитировать
Не, не понял. Что такое статические структуры?
Правильнее было сказать: статически объявленные экземпляры структур, т.е. не в динамической памяти (затрудняюсь более грамотно сформулировать)

Цитировать
Не. Можно без конструкторов. Просто синтаксис для инициализации рекордов. Если полей много - делается обычная вспомогательная функция-конструктор. Ничего в язык добавлять не надо.
Точно ничего? А выделять память отдельной операцией будете? Чем поможет вспомогательная функция-конструктор, если инициализировать всё равно одной командой нужно? Как инициализировать расширенные записи при желании использовать код для базовых записей?

Цитировать
Не, не понял. Обсуждаемые свойства никак не мешают данным модуля - всегда есть OPTIONAL. Просто теперь все будет явно: если данные модуля не могут быть проиничены самостоятельно - то они OPTIONAL.
Что не понятно, конечно optional всегда может инициализироваться по месту, что и скрашивает отказ от данных, которые не могут. Тем не менее, данные могут гарантировано инициализироваться в секции инициализации, но они всё равно должны объявляться через optional. Это точно не влечёт дополнительных расходов со стороны программиста и программы в виде явных и неявных проверок/приведений типа?

Цитировать
Да, да. Давно пора нормально инициализировать массивы :) Если массив большой - да, есть проблема в дополнительных накладных расходах. Но мне не кажется, что это что-то принципиальное. Ну зачем может быть нужен неинициализированный большой массив? Жуткую матрицу посчитать? Так оно считать будет много дольше, чем инициализировать.
К примеру, транспонирование матрицы - штука быстрая. А если это массив структур, содержащих массивы?

Цитировать
Цитата: Comdiv
Отказ от 1-го RETURN (Оберон ведь движется в этом направлении)
А может это неправильное направление? :)
Правильное. Не могу припомнить сколь-нибудь серьёзную проблему, связанную именно с неинициализированной переменной, а вот функции по нескольку тысяч строк, плохо поддающиеся пониманию и переработке из-за усеянности на самом деле ненужными return-ами мне встречаются регулярно. Надо ведь помогать программисту правильно, не так ли?

Цитировать
В приведенном вами примере - компилятор ничего не сможет сделать. Придется инитить мусором, чтобы его заткнуть. В чем мы выиграли?
Я бы и не хотел, чтобы компилятор вопил по этому поводу. Это должно остаться на уровне стороннего анализатора. А помимо компилятора, код просматривает и человек, вот тут-то мы и выигрываем.

Цитировать
В том, что я описал, нет ничего нового. Оно в том или ином виде присутствует в существующих ЯП. Так что каких-то злобных последствия я не предвижу.
В том-то и дело, что включались эти средства по большей части без большого осмысления (говорю это, основываясь ни на чём), а комбинации с запретом на неинициализацию вряд ли есть где-то. Многие не видят и более простых последствий и в ус не дуют. В языке С++ тоже уже сюрпризов нет, а писать на нём хотят всё меньше.
« Последнее редактирование: Февраль 23, 2011, 07:05:55 pm от Comdiv »

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Приспособим PureBuilder для разработки игр
« Ответ #44 : Февраль 23, 2011, 08:02:39 pm »
1.Необходимость больше писать приведёт к тому, что фишкой не будут пользоваться. Перепишите пример со структурами и сравните. Вспомните хотя бы, как сишники жалуются на "многословность" синтаксиса Оберона.

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

Цитата: Comdiv
2.Как минимум нужно и объявление типа по месту.

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

Цитата: Comdiv
Цитировать
Чего ж там сложного??? Компилятор уже умеет иметь дело с временными переменными (для вычисления выражений). Объявление по месту - такая же временная переменная.
Не знаю, не пробовал реализовать, но интуитивно чувствую, что не очень это просто для понимания компилятора, когда группу чего-то отдельного, можно представить как одно и наоборот.

Для понимания компилятора там самое сложное - разобраться с областями видимости. А так.. не знаю... ИМХО все просто.

Цитата: Comdiv
Тернарный оператор намного проще, особенно если не как в С, а как-то так :
Цитировать
TOP(condition, value1, value2);

Ну такая функция все равно будет встроенной, так что не знаю, ИМХО не должно быть трудностей.

Цитата: Comdiv
Правильнее было сказать: статически объявленные экземпляры структур, т.е. не в динамической памяти (затрудняюсь более грамотно сформулировать)

Ну так - инициализировать при объявлении. Что не так?

Цитата: Comdiv
Цитировать
Не. Можно без конструкторов. Просто синтаксис для инициализации рекордов. Если полей много - делается обычная вспомогательная функция-конструктор. Ничего в язык добавлять не надо.
Точно ничего? А выделять память отдельной операцией будете? Чем поможет вспомогательная функция-конструктор, если инициализировать всё равно одной командой нужно? Как инициализировать расширенные записи при желании использовать код для базовых записей?

Ну, допустим у нас есть такой синтаксис для инициализации:
TYPE X = RECORD a: INTEGER; b: INTEGER; END
...
VAR x:= X{1, 2}; // локальная переменная

Выделение в хипе:
VAR x:= NEW(X{1, 2});

Функция-конструктор:
PROCEDURE construct_x(): X
BEGIN
    RETURN X{1, 2};
END construct_x

Расширение записи (Y наследуется от X с добавлением одного поля):
VAR y:= Y{X{1, 2}, 3}; // локальная переменная

Использование функции конструктора:
PROCEDURE construct_y(): Y
BEGIN
    RETURN Y{construct_x(), 3};
END construct_y

Цитировать
Тем не менее, данные могут гарантировано инициализироваться в секции инициализации, но они всё равно должны объявляться через optional. Это точно не влечёт дополнительных расходов со стороны программиста и программы в виде явных и неявных проверок/приведений типа?

А. Понял. Нет. Просто данные модуля инициализируются так же как и локальные переменные - при объявлении. Инициализация таких данных происходит до вызова секции инициализации модуля.

Цитировать
К примеру, транспонирование матрицы - штука быстрая. А если это массив структур, содержащих массивы?

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

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

Дык, согласитесь, что оригинальная проблема в функциях на 1000 строк, а не в RETURN. Думаю вы бы скорее согласились сопровождать функции на 10 строк с RETURN, чем на 1000 строк без RETURN? ;)

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

Человеком ваш код тоже воспринимается непросто. Лично мне понятнее переделанный вариант.

« Последнее редактирование: Февраль 23, 2011, 08:05:25 pm от vlad »