И ? Религия не позволяет +1 делать в суть двух функциях C API ?) Я встраивал и Си в луа и луа в си - у меня в плане индексации трудностей не возникало, там это всё спокойно происходит, на моей памяти только сопрограммы и сложные замыкания требуют внимания и танцев с бубном при встраивании.
Используемые термины зависят от языка. Например в C++/Pascal/Oberon ссылка — это псевдоним переменной, он не владеет переменной (его срок жизни не больше, чем у оригинальной переменной) и не может быть NULL. Указатель может быть владеющим (в системах со сборкой мусора обычные указатели — владеющие, weak pointer надо объявлять явно) и он может быть NULL.
Ссылка — это конкретный объект, безотносительно его физического расположения, а указатель — адрес в памяти, безотносительно того, что там лежит.
В какой книге так написано? Для адреса в памяти и есть термин «адрес», а не «указатель».
КиРу почитай, указатель это объект, который хранит значение адреса, даже цитата с 41-ой страницы: «Для этого вызывающая функция должна передать адрес переменной(в понятиях С - указатель на переменную)»
ну так это присходит из-за того, что ссылка виртуальная, на уровне пользователя-программиста или ВМ, внутри это лишь ключ таблицы и обращение мы ведём по ключу-псевдониму. В рамках ВМ говорить о оригинале несколько нагло, даже в Java в которой прямым текстом всегда пишут что передача идёт по ссылке внутри вы не можете полностью контролировать объект(вам воспрешён доступ до его сырого-оригинального представления)
указатель это объект, который хранит значение адреса
В Lua тоже неявный указатель на таблицу — это объект, который хранит значение адреса таблицы. Помимо хранения адреса указатель может выполнять и другие функции, такие как владение памятью (std::unique_ptr, std::shared_ptr, указатели в системах со сборщиком мусора).
в понятиях С
В итоге пришли к тому, о чём я говорил: в каждом языке своя система понятий и нет единственно правильной.
Я ему про общий, он про частный. «Ты как всегда в своём репертуаре».
Lua никогда и не позиционировался как язык общего назначения, ну.
Про встройку вообще не в курсе, кому там интерпретаторы нужны
В геймдеве очень часто юзается, в расширябельных фреймворках (но многие почему-то изобретает велосипед-недоязык под свои нужды, вместо того чтобы взять тот же Lua, который как раз под такую задачу и заточен), в embedded (просто потому что он лёгкий).
но меня здесь уверяли что джаваскрипт успешно юзают.
ЛОР — так себе источник. На JS из вот прям популярного расширяется разве что PolicyKit (ибо альтернатив ему тупо нет) и GNOME Shell. Ну и, естественно, браузеры, но там JS — родной, так что оно само собой разумеется.
Чем занимаешься?
Я кот, работаю по специальности. :3
не ради срача
А почему бы и ДА? ☺ Под GPL ничего не коммитил принципиально, потому мой код в опенсорсе встретить невозможно.
Помимо хранения адреса указатель может выполнять и другие функции, такие как владение памятью
Нет, ни указатели, ни переменные не могут управлять своим владением, это делают ВМ(например через СМ) по своим правилам, какие бы они не были и разного рода «умные» указатели - это лишь трюк использующий организацию области видимости и хранения в которые замкнуты классы
В итоге пришли к тому, о чём я говорил: в каждом языке своя система понятий и нет единственно правильной.
Подвох в том, что это понятие указателей - общепринятое и значит как раз вывод в том, что ваше представление расходиться с общим - ваша воля подменять смысл понятия, но я всё же считаю, что работать нужно с определением введённым автором или по крайней мере уточнённым продолжателем, а не личной хотелкой называть небо землёй, а землю - небом.
Lua прекрасно справляется со своей задачей — дёргать API языка в который встроен чтобы расширять функционал. Писать что-то серьёзное/самодостаточное на Lua — совершенно неблагодарное занятие. Таким занимаются либо фанатики (чтобы доказать что можно, хотя с этим особо никто и не спорит: хлеб→троллейбус), либо некомпетентные (освоил один язык и давай писать на нём всё!).
Нет, вы в си делите целые, в таком случае результат - целая часть от деления(т.е. у вас округление тоже вниз) и я как раз и использовал целочисленное деление, чтобы было соответствие, чтобы у вас было округление вверх нужно было сделать так (b-a+1)/2, плюс в случае нечётной длины интервала разность была , чётной, ну у вас как я понимаю получается подвох в том, что вы не вклбючаете правую границу в подмассив.
Что это? Virtual Machine? В Обероне и Го нет никакой виртуальной машины, всё компилируется в нативный код, при это есть трассирующий сборщик мусора. std::unique_ptr тоже работает без виртуальной машины.
но я всё же считаю, что работать нужно с определением введённым автором
А код исполняет кто ? Эльфы ? Виртуальная машина ес ть всегда, вопрос только в том, что её можно сделать плоской и уже в рамках плоской(настоящей машины исполнить код), в рамках которых Железо, ОС и окружение будут выполнять роль ВМ. ВМ - это абстракция-отображение, а не только программа которая будет непосредтсвенно обрабатывать псевдокод.
Такая терминология у Вирта (Оберон) и в C++.
А я думал что плюсы придумала команда во главе с Страуструпом, если по вашему всё изобрёл Вирт - это ваше воображение, сами с ним мучайтесь, но определения вправе вводить только авторы «новых сущностей» и переводчики, что возьмут сущность из другого языка, остальное должно хотя бы в разумных пределах пониматься однозначно.
Rust — это Z̵̧͖͓͈̻̬̳͉̍̇͊̀̆̊̽̚͘̚͜͝a̷̢̝̦̯͖͓̲̹̬͉̯̗͓̺̟͚̣̺̘̯̞͇̘͂̽̈́̒͒̊͒͂́͒̾̉̑̓͊̔͌̕͠͝͝ͅḷ̵̡̢̧̧̤͓̹̞̙͈͈̙͍̝͙̦̱̖̤̐̍ͅͅg̷̡̢̛̛̬̻̤̠͇̪̫̯͍͔͓̠̘̀̎͌̿́̄̉͌̇́͐́̈̈͌̎̅̅͗̉͝ͅō̷̡̱̬̲̗͚̼̞̼̯̓̏̉̌̂̿̾̀̐͂̋̎̋̑̑̀̀̚̚̚ среди ЯП, но он всё же на игрушечный в отличие от сабжа.
#include <stdio.h>
int main()
{
int arr[4];
int a, b, c;
a = 0;
b = 4;
c = a + (b - a)/2;
for (int i = a; i < c; i++) arr[i] = -1;
for (int i = c; i < b; i++) arr[i] = 1;
for (int i = a; i < b; i++) printf("%d\n", arr[i]);
return 0;
}
Вывод:
-1
-1
1
1
Lua:
arr = {}
a = 1
b = 4
c = a + (b - a) // 2
for i = a,c-1 do arr[i] = -1 end
for i = c,b do arr[i] = 1 end
for i = a,b do
print(arr[i])
end
Вывод:
-1
1
1
1
Так что fail. Причём в вашем случае даже чётная длина некорректно обрабатывается. Получилась наглядная демонстрация высокой вероятности ошибок при использовании индексов с 1.
Ну не сказал бы что это честно с логики того что вы устраиваете пересменку значений((b - a) // 2) - очевидно, что даст разные значения при разных a, но одинаковых b), проще говоря тогда либо нормализуйте (b - a + 1) // 2), либо тогда центр сместить - выглядеть будет практически также.
arr = {}
a = 1
b = 4
c = a + (b - a) // 2
for i = a ,c do arr[i] = -1 end
for i = c+1,b do arr[i] = 1 end
for i = a,b do
print(arr[i])
end
Поэтому конечно fail, но язык показывает себя хорошо.
Вы понимаете что это всё плод привычки ? Содержательного оправдания предпочтению полуинтервалов над отрезками нет, более того на уровне логики мы обрабатываем отрезки и сортируем конечные отрезки, поэтому такое отношение опрадано только привычкой писать цикл i < n и на уровне логики это оправдано принятием индексации с 0, что тоже неинтуитивно алгоритмически, хотя и оправдано средствами языка и железа, поэтому думать в рамках перечислимых конечных множеств - проще с индексами на отрезках [1,n], а код писать уже в зависимости от языка.
поэтому думать в рамках перечислимых конечных множеств - проще с индексами на отрезках [1,n]
Нет. При работе и интервалами (разбиение и т.п.) легко ошибиться. [0, n), [a, b) — наиболее простое и понятное решение. Длина = b - a. Подинтервалы: [a, c), [c, b). Никаких +-1.
В случае с полными интервалами [a, b]. Длина: b - a + 1. Подинтервалы: [a, c - 1], [c, b] или [a, c], [c + 1, b].
Во-первых [] - отрезок, [) - полуинтервал, () - интервал, во-вторых в том то и прикол, что индексируем часто, длину берём редко, поэтому при отрезке мы всегда чётко сразу знаем крайние элементы, с полуинтервалом вам придётся помнить либо о -1 при обращении к последнему эл-ту, либо о *<* n при проходе по массиву, более есть знаю алгоритмы которые обрезают(не трогают) края(например сглаживание) и в случае отрезка вырез выглядит симметрично, в случае полуинтервала имеем первый индекс например 1, а конечный n-2, а тут мы теряем немало так интуитивности на уровне алгоритма и будет путаница/частые опечатки с < n и < n-1
Иронично, но [a,b)+[b,c)==[a,c) - не проще, чем [a,b]+[b+1,c]=[a,c], если конечно понятие сложности по вашему != экономии двух знаков(=экономия на спичках), а экономия на логических ошибках, так первый пример это сцепка дискретных множеств, а второй по сути объединение дискретных множеств через аппарат действительных чисел, т.к. даже запись [a,b) в рамках дискретки - грубая, т.к. правильнее так [a,b-1], т.к. полуинтервал внутри содержит понятие предела, которое вы вместе с x512 опускаете. Даже иронично, но чтение [a, b] - «отрезок от а, до b», короче чем [a,b) - «полуинтервал от а, до b, не включая b» - ну это если вы про экономию печатных знаков хотите поговорить.
Иронично, но [a,b)+[b,c)==[a,c) - не проще, чем [a,b]+[b+1,c]=[a,c], если конечно понятие сложности по вашему != экономии двух знаков(=экономия на спичках), а экономия на логических ошибках
Я представляю индексы массива как позиции границ между элементами, а не сами элементы. Как то так. Тогда все операции и индексами, интервалами и адресами становятся очевидны. Пример использования: стек вызовов.
даже запись [a,b) в рамках дискретки - грубая
Пишите [a, b) ∩ ℤ, если вас так волнует строгость.
Даже иронично, но чтение [a, b] - «отрезок от а, до b», короче чем [a,b) - «полуинтервал от а, до b, не включая b»
Я всегда говорю «отрезок от а, до b», подразумевая полуинтервал. Если надо, в начале документации написать «везде используются полуинтервалы».
Маск для того, чтобы хоть что-то подобное адекватному AI для доты тратит десятки/сотни миллионов долларов в год на прожигание мегаватт. И все равно не получается лучших игроков одолеть.
Все ждал, когда же ты наконец ворвешься, как рыцарь на белом коне, и начнешь защищать свой любимый язычок, вместо того, чтобы, например, предметно перечислить недостатки и достоинства (по-твоему мнению) обоих проектов. Ничего хуже нет языкового фанбойского отребья. Грустно это.