Болталка PascalABC.NET

Среда PascalABC.NET
#1802

Да, спасибо. Так конечно писать нельзя. Не будем делать Cache для функций без параметров. Потому что изменятся a,b,c в основной программе - и всё - cache будет считать неверное значение

1 лайк
#1803

Интересное поведение. А с чем это связано? , если не секрет

#1804

Помогите перевести код с с# на pascalabc.net:

Код 
foreach (var attachment in message.Attachments) {
    var fileName = attachment.ContentDisposition?.FileName ?? attachment.ContentType.Name;

    using (var stream = File.Create (fileName)) {
        if (attachment is MessagePart) {
            var rfc822 = (MessagePart) attachment;

            rfc822.Message.WriteTo (stream);
        } else {
            var part = (MimePart) attachment;

            part.Content.DecodeTo (stream);
        }
    }
}
#1805

Лайфхак - компилируешь и вызываешь из паскаля

#1806

а что если…

procedure x(a, b, c: integer);
begin end;

begin
  x(readlninteger3);
end.
#1807

Но думаете что создавать глобальное состояние - это решение по-лучше?

Компилятор не магию использует для [Cache].
Ускорение достигается тем, что когда понять что результат будет таким же (потому что такие же значения на входе) - он не пересчитывается, а берётся из словаря, сгенерированного для этого метода.
Теперь вопрос - как он поймёт когда результат будет таким же, а когда другим?
Можно сделать очень сложный алгоритм, ищущий все использованные в подпрограмме переменные, но параметры уже указывают это явным образом.

#1808

Тут почти все переводится строчка в строчку, хотя я вижу пару сложных моментов.
Нужен контекст этого кода + ваши попытки - чтоб я не всё за вас делал, а подсказывал.

#1809

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

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

#1810

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

К примеру, объявить внутренний массив (в вашем случае список) пользовательским типом, и инкапсулировать все операции с ним.

#1811

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

#1812

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

Помощь новичкам
#1813

В свое время меня это тоже “забавляло”. Потом привык…

#1814

Да лучше разработали бы все компактно, и не было такие проблемы. Но думаю разработчики примут это в будущем.

#1815

“Все компактно” - это уже было. У Н.Вирта. Вот только как раз по этой причине и умерло.

#1816

А? А что, а почему, а как?

#1817

Вам как, всю историю языка Паскаль за 50 лет изложить? Или все же сами в Интернет поищете?

#1818

Если вы считаете что-то важным рассказать - милости прошу, ни буковки мимо глаз не пропущу Если же нет - ну, нет так нет. Не настолько важная информация, чтобы её искать

#1819

Верно. Не настолько важная. Но тогда не пытайтесь тут устроить филиал “Что? Где? Когда?”. Не получится.

#1820

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

Давно уже, задолго до PascalABC был разработан более прогрессивный язык Modula-2 с улучшенным по сравнению с паскалем синтаксисом и большими возможностями. Можно было бы сделать на её основе систему, а не на Паскале. Дальше ещё были Modula-3, Oberon и тд, но там уже не так много было улучшено.

#1821

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