А что здесь сложного и не оптимального? Узнаём используется ли слайс несколькими объектами, если да клонируем в новый слайс и говорим что старый слайс нам больше не нужен.
Или это следствие того, что стандартные функции тоже написаны на Вашем же творении?
Я стараюсь как можно меньше «пихать» в компилятор и по больше выносить в библиотеки.
мы копируем на стек 56 байтов (вызов use), чтобы затем снова скопировать на стек 56 байтов (вызов clone). Зачем ТАК сильно игнорировать указатели?
Use помечен как always inline так что ничего копироваться не будет, clone просто inline так что есть вероятность того, что clone также будет заинлайнен. Вообще я много изучал как оптимизирует llvm и clang, многие вещи написаны на первый взгляд не оптимально, но они написаны так, чтобы clang хорошо этот код оптимизировал, такую простую оптимизацию как передача значения через указатель, вместо копирования на стэк, clang делает даже на уровне оптимизации O0 (только что проверил на типе размером 56 байт).
Выходит, что useCounter нулевой (т.е. nullptr) у a_/b_, но почему-то не пустой у c_. В чём принципиальная разница? Видимо, в том, что строки «hello» и «hello 2» являются константами, а «Hello» – «собрана на куче»?
Да. Когда строки являются константами — им незачем счётчик, но для изменения буквы в c, строку необходимо было скопировать в кучу.
Тогда, наверно, «на куче» будет всё, кроме константых строк?
Нет. В данный момент только 2 типа имеют данные на куче, это Slice и Fluid.
Ну ещё константных массивов, по аналогии с int arr[] = { 0, 2, 4, 6, 8};?
Из слайсов пока к сожалению только строки так могут.
Переменная a – «на стеке» или «на куче»?
На стэке.
Так-то на стеке будет лежать только структура, а сами данные будут в куче?
Нет, всё на стэке.
Соответственно, в методе mutateLine счётчик на линии будет равен двум
Тут нет ни одного счётчика. Пока он есть только в Slice и Fluid, а здесь только UInt64 и Float.
Всё равно не понимаю.
Давайте приведу пример на си, который изобразит то, что происходит на приведенном вами примере.
#include <inttypes.h>
struct point{
uint64_t x, y;
};
struct line{
struct point a, b;
};
struct point createPoint(uint64_t x, uint64_t y){
return (struct point){.x = x, .y = y};
}
struct line createLine(struct point a, struct point b){
return (struct line){.a = a, .b = b};
}
void mutateLine(struct line *line, struct point p1, struct point p2, float f1, float f2){
//здесь line изменяется
}
int main(){
struct line a = createLine(createPoint(0, 0), createPoint(1, 1)); //a храниться на стэке (на саммом деле там где clang решит)
struct line b = a; //в a не храниться ни каких указателей на кучу
//данные копируются из стэка в стэк (как clang решит)
//вызовы use и free - безсмыссленны (для типов без указателей они вообще не вызываются)
mutateLine(&a, createPoint(2, 2), createPoint(3, 3), getRandomFloat(0, 1), getRandomFloat(0, 1));
//для того чтобы изменить a, нужно передать ссылку на a
return 0;
}
Строки 266-269 – use(newItem) есть, а free(oldItem) – нет.
Нет это не баг, use для newItem вызывается в программе явно, а free должен вставлять компилятор, но компилятор видит, что тип UInt8 и не вставляет бессмысленный free.
Пока всё что есть это этот блог, но я там стараюсь писать в начале простые вещи, а затем более сложные. То о чём вы спрашиваете — это закулисы, а о них я собирался не скоро писать, не говоря о том, что я немного застопорился в блоге, по скольку следующая статья которую я хотел писать о том, что очень сильно меняется в версии 0.2 которую я постараюсь выпустить к 1 февраля (но не факт, что успею). Но если вас интересуют какие либо подробности — Telegram — taetricus.13, почта — 0.cine.developer@gmail.com. Отвечаю не очень оперативно, но отвечаю.
или пример собранного C-кода, который получается с подобного блока?
В этом комментарии есть пример кода на си который иллюстрирует как всё происходит (на самом деле генерируется другой код).
Вот если по Вашим примерам – есть точки, есть линии. Причём точка – tuple двух координат, а линия – tuple двух точек. Я вызываю функцию, передаю туда линию, две точки и два float (t1/t2). Функция должна сделать два Lerp между двумя переданными точками (используя t1/t2), и результаты Lerp'ов записать в line:a и line:b.
Линия, которая передаётся в функцию, не проходит же Copy-on-Write заранее?
Copy-on-Write происходит только в одном случае — изменение данных располагаемых на куче, если на эту кучу есть несколько указателей, Copy-on-Write происходит непосредственно в момент изменения. В указанном вами примере line хранится на стеке и его изменение никогда не вызовет Copy-on-Write, как бы line не изменялся. Предположим, что есть тип BigesFloat который может хранить число любого размера, а данные он хранит на куче. Предположим p1 точка с координатами типа BigestFloat, то line:a = p1 всё равно не вызовет Cope-on-Write, поскольку память на куче не меняется, здесь просто line:a будет хранить указатель который находится и в p1, память по указателю не будет изменена.
Не совсем понимаю, что значит «хранится на стеке», и как может при Вашем подходе на стеке храниться что-то кроме value type variables и указателей на объекты (с счётчиком ссылок).
Я думаю по приведенному вышке примеру на си (из другого комментария) будет понятно, что к чему, но на всякий случай дам пример на cine и во что он генерируется на си.
Вот код на cine:
proc main()
a := "hello"
b := a
c := a
b = "hello 2"
c:setFirst('H')
a.printLn()
b.printLn()
c.printLn()
Код на си (генерируется компилятором которые когда допилится станет 0.2, поэтому код отличается от такового из версии 0.1)
Но структура же тоже объект? Или это два разных типа сущностей?
Как было сказано в статье, я при проектировании приложений задействую ООП (хотя язык и не ООП), а в ООП программа представляется в виде объектов которые взаимодействуют друг с другом. Под объектом я понимаю любые данные имеющие тип, где они располагаются — не важно. Счётчики не относятся к объектам, счётчики относятся только к памяти выделенной на куче. Вот пример кода на си, илюстрирующий то о чём я говорю (На всякий случай скажу, что в cine нет массивов, есть только слайсы и можно брать кусок другого слайса не выделяя новую память. Массив в примере только для упрощения кода).
struct array {
uint64_t *counter;
uint8_t *array;
}
struct someType {
uint64_t x;
struct array y;
}
//аналог этой функции есть в стандартном модуле cine
//есть и decCounter но для примера он не нужен
void incCounter(struct array a){
*(a.counter)++;
}
//аналог этой функции сгенерируется автоматически
void incCounter(struct someType a){
*(a.y.counter)++;
}
void foo(){
//код на cine
//a := someFunc()
//someFunc вернёт объект с типом someType
//counter которого равен 1
//похожий код на C
struct someType a = someFunc();
//код на cine
//b := a
//похожий код на C
struct someType b = a; //данные из a просто копируются в b, все указатели из а указывают на ту же память что и указатели в b
incCounter(a); //этот вызов вставится автоматически
//в дальнейшем если какая либо функция захочет изменить a.y.array то она посмотрит на a.y.counter
//и если там число больше 1 - то создастся новый счётчик a.y.counter со значением 1 (в b останется старый счётчик),
//затем выделится память размером как у a.y.array и в эту новую память копируется память из a.y.array
//после чего в a.y.array помещается новый кусок памяти (в b.y.array остаётся старая память) при этом если в a.y.array есть какие либо счётчики
//то они все увеличиваются на 1. Если нужно поменять a.x
//то он просто меняется, так как a.x не указатель а просто значение лежащее на стэке (или регистре процессора, как clang решит), изменение
//a.x естественно никак не повлияет на b.x
}
Да, но в этом случае есть большая проблема с тем, что объект не может хранить своё состояние в себе; каждый раз, меняя элемент интерфейса (надпись на кнопке, например), нужно устраивать пляски с бубном, чтобы в контейнере осталась ссылка на обновлённый вариант кнопки, в контейнере-уровнем-выше осталась ссылка на обновлённый вариант контейнера, и так далее, выше, до самого interface root element/container.
Это не обязательно, можно в место ссылки хранить номер индекса виджета в массиве.
Ну или нужно иметь где-то аналог статичного массива (какой-то менеджер), сводящемуся к хешмапу id → состояние объекта, а на каждом элементе держать уникальный id. Думаю, это как-то можно сделать не очень неудобным… Но зачем?..
Не обязательно хэш использовать, можно просто использовать массивы, а id это позиция в массиве.
Вообще у меня есть 6 вариантов создания gui:
Создавать аналоги интерфейсов из многих других языков, все виджеты хранятся в одном массиве в типе Fluid (аналог пустого интерфейса), но поскольку в таких интерфейсах «методы» не могут менять сам объект, они могут в качестве результата возвращать новый объект, а затем этот новый объект поместить назад в массив.
Весь GUI храниться в одной структуре которая хранит по одному массиву на каждый тип виджета. При изменении виджета по его типу определяется массив куда новые значения нужно поместить
Создавать один массив со всеми виджетами внутри Fluid, любая функция применяемая к виджету, применяется непосредственно к Fluid, а внутри Fluid уже определяется что это за тип виджета и как с ним поступать, затем изменённый виджет опять помещается в Fluid, а затем в массив.
Создать программу в которой можно удобно создавать GUI, а на выходе эта программа генерирует код создающий такой GUI с указанным поведением и с любыми возможными костылями необходимыми для реализации подобного GUI, а также создать модуль для удобного взаимодействия с этим GUI.
Нет. Просто было 75 новых комментариев, а в ЛС пришло письмо об орфографической ошибке, открыв статью для исправления ошибки — я автоматически сбросил счётчик новых сообщений, для ответа (при необходимости) на новые комментарии мне нужно пролистать полностью все комментарии (теперь я понял насколько божественна система на linux.org.ru, когда все комментарии идут подряд без ветвлений). Для нахождения всех новых комментариев мне нужно много времени, нашёл я время только спустя 2 недели, но раз я уже сел отвечать — ответил на все, даже на те на которые стоило бы не отвечать.
Ну если есть код, его можно запустить на компиляцию и самому, или спец скриптом, ничего нового…
Обычно у программ есть зависимости которые перед компиляцией нужно удовлетворять, а здель собирается один пакет в котором всё есть. Обычно разработчики распространяют свои программы в бинарном виде и не делают ни каких специальные оптимизации под конкретное железо, поскольку расспространятся оно будет скомпилированным под какой-то древний ПК (в статье об этом указано).
Юзер будет просто счастлив.
Я как пользователь был бы счастлив, но поскольку никто кроме разработчиков Gentoo этого не делал — сделал я. Как это реализованно в Gentoo мне не очень нравится.
Это и знающих лишь винду задолбало(далее далее, да ка-бы согласен(нет), далее), а уж у сидящих под линуксом(привыкших в основном к установке из пакетов, или компиляции из исходников) вызовет припадок(для таких вещей есть конфиги, проверки, ключи и прочее).
Эту возможность необязательно использовать, она опциональна. Cine и fei — ничего не спрашивают.
Особенно хорошо если юзер не знает или выберет то что не поддерживается системой.
Программа для видео монтажа может использовать cude или opencl, монтажёру можно предоставить выбор до установки и в итоговой программе не будет намёка на неиспользуемую технологию, что позволит уменьшить потребление ресурсов. Я думаю большинство проффеcсиональных монтажёр знает о opencl и cuda, не говоря о том, что вопрос не имеет ограничений на количество символов и можно при постановке вопроса всё объяснить и дать рекомендации.
Куду вроде так и нельзя(костыли не рассматриваем) запустить на АМДшках, не?
В этом случае можно написать в вопросе то, что если у вас видео карта от AMD cuda вам не доступна.
Эта ниша же такая пустая
Я не по тому язык создал чтобы заполнить нишу, а потому что для меня не было подходящего инструмента.
Опять же, неизвестную фигню ставить(ну как упадёт)? А потом удивляться куда это просраны расчеты, да.
Чушь не надо пороть.
Не стоит ли уважать силы сообщества?
Уважаю.
Языков уже слишком много
И это хорошо, ведь есть выбор.
пользы от пачки новых «СУПИРЯЗЫГ9000 BUENO EDITION» нет
Не вам судить
ладно бы софт или библиотеки\фреймворки делали(хоть и клоны существующих),
Так займитесь этим, вместо пустой критики.
По сути это нужно лишь индустрии
Это нужно мне. И я без всяких мутных личностей решу, что мне делать.
А могут и не оказаться.
Вполне, возможно. Но никто никого не заставляет.
я считаю что разумнее или учавствовать в допиливании его.
Присоединяйтесь к сообществу и помогайте, я не против.
Скажем если алгоритм дрянь — менять надо его, а не язык.
А если алгоритм и так хорош, а на разработку нового уйду годы.
Алгоритмы конечно больше решают чем язык, но чушь пороть не надо.
Это говорят про каждое первое поделие.
Ни разу не слышал таких заявлений по отношению к rust и idris.
так что аргумент так себе
А по мне — очень сильный аргумент.
Всё передаётся по значению?
На уровне языка да.
Если нет — оно всё еще там, тока под капотом
Под катом да, но изменение значения одной переменной, не может повлиять на значение другого — а это решает все мои проблемы в языке.
да и явное указание лучше, всегда знаешь что тут тока инт, тут только дабл, а вот тут — что угодно
То есть статью вы не читали но сразу побежали комменты строчить? Язык имеет строгую типизацию и всегда знаешь, что где хранится.
Так тут дело в кодере, зачем из-за этого 12 лет городить язык?
Ну это вообще детский сад, все делают ошибки в коде, если вы нет — жду от вас статью о том как вы стали богом кодинга, с удовольствием прочту. А я просто взял и создал инструмент на котором я не могу совершить свою самую распространённую ошибку. Вам это не нравится — не используйте.
«b:field = value») «отделение» переменной b уже сработало
В случае с b:field = value «отделится» сдесь может только field, а b храниться на стеке и если ему присвоить какое то d, то на уровне программы содержимое d полностью скопируется (это не затратно) в b, но если например в field есть указатель на массив, то массив не будет скопирован, а просто для этого массива счетчик увеличится на 1.
точнее будет, наверно, всё-таки транспайлер
Неверно.
Транспиляция — преобразование программы, при котором используется исходный код программы, написанной на одном языке программирования в качестве исходных данных, и производится эквивалентный исходный код на другом языке программирования.
Cine не производит эквивалентный код.
Компиля́ция — сборка программы, включающая трансляцию всех модулей программы, написанных на одном или нескольких исходных языках программирования высокого уровня и/или языке ассемблера, в эквивалентные программные модули на низкоуровневом языке, близком машинному коду (абсолютный код, объектный модуль, иногда на язык ассемблера) или непосредственно на машинном языке или ином двоичнокодовом низкоуровневом командном языке и последующую сборку исполняемой машинной программы.
Мне без разницы названия, но vala, nim, haxe — для них есть компиляторы итогом которых служит код на Си. И все называют их компиляторами и это абсолютно верно, транспайлер не подходящее слово. Транспайлеры обычно служат для преобразования исходного кода на одном языке в исходный код на другом языке, но таким образом, чтобы человек мог с результирующим кодом работать, с тем что генерирует cine — очень тяжело работать.
result:x = x
result:y = y
На всякий случай поясню, счётчика у result нет! Внутри result могут быть указатели на память в куче и вот только на такую память есть счётчики. Присвоение нового значения x никак не может вызвать копирование каких либо данных со счётчиком, но может повлиять на сами счётчики (если они есть) внутри x, на y это не оказывает ровным счётом никакого влияния.
методов
В языке нет методов — только функции, невнимательно прочитали статью, финальный вариант языка не ООП.
сохранять ссылку на this
Ссылки и указатели можно было использовать только в самом первом варианте языка (который не ООП), когда язык был уже ООП никаких ссылок не было, а те что были на уровне программы, а не языка, не могли хранить ссылки на переменные, аргументы методов и тд, поскольку они были только на стэке.
И, кажется, в языке не хватает библиотечной части. Можно добавить interop с C, «unmanaged» небезопасный слой.
Там C используется как inline asm, можно хоть целые функции писать, можно подключать C библиотеки, но пока их нельзя в пакет включать (но планируется).
К сожалению не помню полное название модели, но точно помню 800 Mhz, 64 Mb оперативной памяти, 14 Gb жёсткий диск, встроенное видео с разрешением 640 x 480 и 16 цветов. Встроенное видео было не в процессоре, а в материке.
Вы понимаете, что вы юлите не перед нами, а перед самим собой.
Не юлю, а не хочу отвечать полноценно на глупые вопросы.
Если вы сами не знаете зачем он вам нужен
Вы статью хоть читали?
как же вы объясните другим людям — зачем им этот инструмент?
Этот инструмент для решения моих проблем в разработке. Я уверен что раз проблема есть у меня — она есть и у других. Не говоря о том, что заинтересованные уже нашлись.
Если он вам нужен для обучения и оттачивания скилов, либо потешить свою любознательность
Не нужно гадать — почитайте статью и комментарии.
значит продукт вашей деятельности нужен только вам.
Но погодите — зачем совершенствовать именно его? В мире есть масса других инструментов, которые можно бы поусовершенстсовать…
С удовольствием занялся бы этим, если бы изначально был совместимый для моих целей инструмент. Его не было (или я не знаю о таком) — пришлось делать свой.
Для разработчи чего, извините?
Компьютерных программ.
Понимаете — у вас так получается, что у вас есть инструмент, который используется для разработки этого самого инструмента…
Это инструмент не единственный, это единственный который я опубликовал в интернете. А сколько интересных идей у меня в голове сидит.
у меня есть классный способ разрабатывать web-сайты, быстрее и удобнее, чем другие — но нужно изучить Ruby
Я уверен, что ему тоже многие говорили, что за чем ты это делаешь есть же «любой другой язык»? Зачем ты велосипеды изобретаешь?
У вас же есть две задачи: улучшение языка и использование этого языка для улучшения языка.
Мне кажется, или при таком подходе проблемы с написанием кода будут на каждом шагу?
Уже попробывал на практике, проблем стало гораздо меньше.
Например, есть массив/коллекция/хешмап (в общем, какой-то контейнер) с объектами. Получается, что если нужно поменять состояние одного из объектов – нужно достать объект (по факту – ссылку на него) из контейнера, затем отредактировать объект, после чего придётся заменить значение в контейнере на новое. Правильно?
Верно, но меня это устраивает.
Причём получаем следующую ситуацию – в момент редактирования срабатывает Copy-on-Write, потому что ссылок на объект минимум две (в контейнере и изменяемая).
Допустим элементы массива являются структурой хранящей два члена, один число (UInt64), а второй массив. При получении элемента из массива значения числа и указатели на память массива копируются на стэк, при этом счётчик у массива внутри элемента увеличивается на 1. Если в полученном элементе изменить число, никакого копирования не происходит, если изменить массив (тот который внутри элемента) то он будет скопирован. При помещении измененного элемента назад в исходный массив если его счётчик будет равен 1, то массив не будет скопирован, иначе будет.
То есть, правильно делать в следующем порядке container.getItem → containter.removeItem → редактирование экземпляра → container.addItem? Тогда на момент изменения будет одна ссылка (если, конечно, копия объекта не хранится где-то ещё), и лишнего копирования не будет…
Это не всегда нужно, но в некоторых случаях это действительно будет оптимизацией.
Похоже, правильно говорят, что будут проблемы даже набросать какой-то несложный GUI.
Возможно, но я вижу несколько возможных и адекватных решений проблемы.
но стандартный вариант, когда есть в том или ином виде контейнер с виджетами, некоторые из которых тоже являются виджетами – явно не для Вашего языка, как я понимаю? Или есть какой-то подход, который позволяет решать эти проблемы по-другому?
Он возможен (поскольку функции являются объектом первого класса и по этому можно делать аналоги интерфейсов из других языков), но мой язык действительно для таких целей подходит менее чем большинство других. Но не стоит забывать, что в языке можно свободно использовать вставки на Си, можно банально сделать бинбинги для GTK.
Я даже не знаю — нужно ли в этом месте смеяться или плакать. Вам отказали в одном месте — и вы расстроились? Почему не пошли в другое, третье, 25е…? Вы что — думаете много програмистов без опыта получают предложение где они «подходят под все требования вакансии» с первого раза?
Для всех кого заинтересовала данная тема, советую посмотреть на liquidhaskell.
Use помечен как always inline так что ничего копироваться не будет, clone просто inline так что есть вероятность того, что clone также будет заинлайнен. Вообще я много изучал как оптимизирует llvm и clang, многие вещи написаны на первый взгляд не оптимально, но они написаны так, чтобы clang хорошо этот код оптимизировал, такую простую оптимизацию как передача значения через указатель, вместо копирования на стэк, clang делает даже на уровне оптимизации O0 (только что проверил на типе размером 56 байт). Да. Когда строки являются константами — им незачем счётчик, но для изменения буквы в c, строку необходимо было скопировать в кучу.Нет. В данный момент только 2 типа имеют данные на куче, это Slice и Fluid. Из слайсов пока к сожалению только строки так могут.
На стэке.Нет, всё на стэке. Тут нет ни одного счётчика. Пока он есть только в Slice и Fluid, а здесь только UInt64 и Float.
Давайте приведу пример на си, который изобразит то, что происходит на приведенном вами примере.
Нет это не баг, use для newItem вызывается в программе явно, а free должен вставлять компилятор, но компилятор видит, что тип UInt8 и не вставляет бессмысленный free.
Copy-on-Write происходит только в одном случае — изменение данных располагаемых на куче, если на эту кучу есть несколько указателей, Copy-on-Write происходит непосредственно в момент изменения. В указанном вами примере line хранится на стеке и его изменение никогда не вызовет Copy-on-Write, как бы line не изменялся. Предположим, что есть тип BigesFloat который может хранить число любого размера, а данные он хранит на куче. Предположим p1 точка с координатами типа BigestFloat, то line:a = p1 всё равно не вызовет Cope-on-Write, поскольку память на куче не меняется, здесь просто line:a будет хранить указатель который находится и в p1, память по указателю не будет изменена.
Я думаю по приведенному вышке примеру на си (из другого комментария) будет понятно, что к чему, но на всякий случай дам пример на cine и во что он генерируется на си.
Вот код на cine:
Код на си (генерируется компилятором которые когда допилится станет 0.2, поэтому код отличается от такового из версии 0.1)
Это не обязательно, можно в место ссылки хранить номер индекса виджета в массиве.
Не обязательно хэш использовать, можно просто использовать массивы, а id это позиция в массиве.
Вообще у меня есть 6 вариантов создания gui:
Обычно у программ есть зависимости которые перед компиляцией нужно удовлетворять, а здель собирается один пакет в котором всё есть. Обычно разработчики распространяют свои программы в бинарном виде и не делают ни каких специальные оптимизации под конкретное железо, поскольку расспространятся оно будет скомпилированным под какой-то древний ПК (в статье об этом указано).
Я как пользователь был бы счастлив, но поскольку никто кроме разработчиков Gentoo этого не делал — сделал я. Как это реализованно в Gentoo мне не очень нравится.
Эту возможность необязательно использовать, она опциональна. Cine и fei — ничего не спрашивают.
Программа для видео монтажа может использовать cude или opencl, монтажёру можно предоставить выбор до установки и в итоговой программе не будет намёка на неиспользуемую технологию, что позволит уменьшить потребление ресурсов. Я думаю большинство проффеcсиональных монтажёр знает о opencl и cuda, не говоря о том, что вопрос не имеет ограничений на количество символов и можно при постановке вопроса всё объяснить и дать рекомендации. В этом случае можно написать в вопросе то, что если у вас видео карта от AMD cuda вам не доступна.
Я не по тому язык создал чтобы заполнить нишу, а потому что для меня не было подходящего инструмента.
Чушь не надо пороть.
Уважаю.
И это хорошо, ведь есть выбор.Не вам судитьТак займитесь этим, вместо пустой критики.
Это нужно мне. И я без всяких мутных личностей решу, что мне делать.Вполне, возможно. Но никто никого не заставляет.
Присоединяйтесь к сообществу и помогайте, я не против.А если алгоритм и так хорош, а на разработку нового уйду годы.
Алгоритмы конечно больше решают чем язык, но чушь пороть не надо.
Ни разу не слышал таких заявлений по отношению к rust и idris. А по мне — очень сильный аргумент.На уровне языка да. Под катом да, но изменение значения одной переменной, не может повлиять на значение другого — а это решает все мои проблемы в языке. То есть статью вы не читали но сразу побежали комменты строчить? Язык имеет строгую типизацию и всегда знаешь, что где хранится.Ну это вообще детский сад, все делают ошибки в коде, если вы нет — жду от вас статью о том как вы стали богом кодинга, с удовольствием прочту. А я просто взял и создал инструмент на котором я не могу совершить свою самую распространённую ошибку. Вам это не нравится — не используйте.
Если есть вопросы — спрашивайте. Telegram — taetricus.13, почта — 0.cine.developer@gmail.com.
Неверно.
Транспиляция — преобразование программы, при котором используется исходный код программы, написанной на одном языке программирования в качестве исходных данных, и производится эквивалентный исходный код на другом языке программирования.
Cine не производит эквивалентный код.
Компиля́ция — сборка программы, включающая трансляцию всех модулей программы, написанных на одном или нескольких исходных языках программирования высокого уровня и/или языке ассемблера, в эквивалентные программные модули на низкоуровневом языке, близком машинному коду (абсолютный код, объектный модуль, иногда на язык ассемблера) или непосредственно на машинном языке или ином двоичнокодовом низкоуровневом командном языке и последующую сборку исполняемой машинной программы.
Мне без разницы названия, но vala, nim, haxe — для них есть компиляторы итогом которых служит код на Си. И все называют их компиляторами и это абсолютно верно, транспайлер не подходящее слово. Транспайлеры обычно служат для преобразования исходного кода на одном языке в исходный код на другом языке, но таким образом, чтобы человек мог с результирующим кодом работать, с тем что генерирует cine — очень тяжело работать.
На всякий случай поясню, счётчика у result нет! Внутри result могут быть указатели на память в куче и вот только на такую память есть счётчики. Присвоение нового значения x никак не может вызвать копирование каких либо данных со счётчиком, но может повлиять на сами счётчики (если они есть) внутри x, на y это не оказывает ровным счётом никакого влияния. В языке нет методов — только функции, невнимательно прочитали статью, финальный вариант языка не ООП. Ссылки и указатели можно было использовать только в самом первом варианте языка (который не ООП), когда язык был уже ООП никаких ссылок не было, а те что были на уровне программы, а не языка, не могли хранить ссылки на переменные, аргументы методов и тд, поскольку они были только на стэке.
Этот инструмент для решения моих проблем в разработке. Я уверен что раз проблема есть у меня — она есть и у других. Не говоря о том, что заинтересованные уже нашлись.
Не нужно гадать — почитайте статью и комментарии.
Повторюсь, уже нашлись заинтересованные лица.
Компьютерных программ.Это инструмент не единственный, это единственный который я опубликовал в интернете. А сколько интересных идей у меня в голове сидит.
Я уверен, что ему тоже многие говорили, что за чем ты это делаешь есть же «любой другой язык»? Зачем ты велосипеды изобретаешь? Ваши домыслы, не более.
Верно, но меня это устраивает. Допустим элементы массива являются структурой хранящей два члена, один число (UInt64), а второй массив. При получении элемента из массива значения числа и указатели на память массива копируются на стэк, при этом счётчик у массива внутри элемента увеличивается на 1. Если в полученном элементе изменить число, никакого копирования не происходит, если изменить массив (тот который внутри элемента) то он будет скопирован. При помещении измененного элемента назад в исходный массив если его счётчик будет равен 1, то массив не будет скопирован, иначе будет.
Это не всегда нужно, но в некоторых случаях это действительно будет оптимизацией. Возможно, но я вижу несколько возможных и адекватных решений проблемы. Он возможен (поскольку функции являются объектом первого класса и по этому можно делать аналоги интерфейсов из других языков), но мой язык действительно для таких целей подходит менее чем большинство других. Но не стоит забывать, что в языке можно свободно использовать вставки на Си, можно банально сделать бинбинги для GTK.
Можно. Переменные хранятся на стэке для них счётчик не нужен.Счётчик есть только у массива.