Заметки о выходе из функции без значения и зеркальности get и put

Выход из функции без значения

. . .
IF A>B THEN RETURN(A); ELSE RETURN(B);
END F;

. . .
IF A>B THEN RETURN(A); // ELSE RETURN(B);
END F;

IF A>B THEN RETURN(A); // ELSE RETURN(B);
END F;

ВОЗМОЖЕН ВЫХОД БЕЗ ЗНАЧЕНИЯ ИЗ ФУНКЦИИ F

О зеркальности get и put

put file(f) data(%include ‘c:\test\param.txt’);

Опубликовано: 2019.02.14, последняя правка: 2022.12.24    20:36

✅  2019/02/14 00:06, Автор сайта          #0 

  fputc( символ_откуда, файл_куда);             // --> слева направо
  fgets( строка_куда, сколько, файл_откуда);    // <-- справа налево

    . . .	// тело функции 1-го или 2-го типа
    0)		// последняя строка функции, здесь подразумевается return 0

    . . .	// тело процедуры (3-й или 4-й тип)
    f(x)	// производим побочный эффект
    g(y)	// не производим побочный эффект
    h(z)	// не производим побочный эффект
    return)

✅  2019/02/16 14:52, kt          #1 

✅  2023/09/20 00:00, alextretyak          #2 

Возник вопрос: кто виноват в потере зеркальности?

std::cout << 12 << 34; // выведет 1234
std::string s = "a b";
std::cout << s; // выведет `a b`, но
std::cin  >> s; // если ввести `a b`, то в `s` запишется только `a`
std::getline(std::cin, s); // эта операция зеркальна `std::cout << s << '\n';`
                           // (но только при условии, что `s` не содержит символа '\n')

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

Когда в языке есть синтаксически обозначенные 1) чистые функции, 2) недетеминированные без побочных эффектов, 3) с побочными эффектами, 4) недетеминированные с побочными эффектами

Если у нас функция, возвращающее значение, имеет 1-й или 2-й тип, то в них и слово «return» не нужно. Возвращаемым значением является последнее выражение

It's kind of just syntactic sugar. But it does make closures easier to deal with:
nums.iter().map(|i|*i).collect()

Without implicit return, |i|*i becomes |i|{return *i;}, which imo seems unneeded.

Вызов функций без побочного эффекта между f(x) и «return» (а это функции g(y) и h(z)) не имеет никакого смысла.

✅  2023/09/24 22:47, Автор сайта          #3 

код для сохранения данных в файл, состоящий из вызовов «fwrite», можно скопировать, а затем заменить «fwrite» на «fread», и получится код для чтения из файла. Этот код, конечно, потребует доработки, но переставлять аргумент FILE* по крайней мере будет не нужно.

при объявлении каждой новой функции программист должен явно обозначать, к какой категории/типу относится эта функция?

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

При этом вводить отдельный метод, который только удаляет элемент массива и ничего не возвращает, нежелательно: во-первых, это плодит сущности, и во-вторых, наиболее подходящее название для такого метода — remove() — уже занято в Python под другое действие.

✅  2023/09/27 00:00, alextretyak          #4 

Хотя можно схитрить. Ключевым словом «функция» обозначать только чистые функции. Для функций с побочными эффектами позаимствовать старое доброе слово «процедура».

✅  2023/09/27 15:43, veector          #5 

В целом я склоняюсь к тому, что спецификаторы функций должны определяться автоматически компилятором (речь идёт о таких спецификаторах как inline, pure, а также const у методов).

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

✅  2023/09/28 11:10, Автор сайта          #6 

 A = {a, b}

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

 x = random()	// аргумент известен во время компиляции, он пустой
 put (y)	// аргумент известен во время компиляции, это y

✅  2023/09/28 16:44, veector          #7 

Не любую, а только чистую. Иначе бы на этапе компиляции можно было бы выполнять такие функции:

 x = random() // аргумент известен во время компиляции, он пустой 

✅  2023/09/30 00:00, alextretyak          #8 

2. Что касается inline-функций, считаю, что допущена более фундаментальная ошибка. Считаю, что решать inline/не inline, должен тот, кто пользуется функцией (по своим критериям), а не тот, кто пишет саму функцию. Например, в одном месте программы мне надо самый быстрый вариант, а значит мне надо что бы было вставлено тело функции (и желательно раскрыты циклы), а не её вызов. В остальных частях программы, мне надо экономить размер кода, поэтому, я желаю что бы компилятор вставлял вызов функции.

__forceinline auto inlined_fn(<some arguments>)
{
    ...
}

template <class... Args> __declspec(noinline) auto not_inlined_fn(Args&&... a)
{
    return inlined_fn(std::forward<Args>(a)...);
}

Не любую, а только чистую.

Иначе бы на этапе компиляции можно было бы выполнять такие функции:

x = random()   // аргумент известен во время компиляции, он пустой
put (y)        // аргумент известен во время компиляции, это y

✅  2023/10/01 15:17, Автор сайта          #9 

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

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

Вот кстати. А почему бы и нет?

для того, чтобы получить детерминированный random … чтобы можно было удостовериться, что алгоритм после переписывания работает правильно.

компилятор не должен выводить y на этапе компиляции. Но он может предвычислить какие-то выражения внутри функции put, чтобы put выполнялась быстрее — например перевести y в десятичную систему счисления на этапе компиляции

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su