Данный участник неуважительно себя вёл довольно продолжительное время, что можно увидеть по его манере речи как минимум. Я решил, что в ближайшее время перестану терпеть любые подобные выходки, даже если эти люди иногда говорят полезные вещи.
Багом, в данном случае, является то, что не запланировано. Деление на ноль с самого начала должно было приводить к неопределённому поведению.
Я ничего не оправдывал и не оправдываю. Я лишь делаю свой личный проект, не претендующий на значимость в текущей системе. Разумеется, лишь я решаю, как его обновлять.
Мне была показана лишь малая часть багов. Весь язык сейчас находится в постоянном изменении, что можно видеть по коммитам. Ближе к релизу 1.20 постараюсь стабилизировать состояние.
На будущее: не прикрывайся объективной критикой, как ты делал это на Discord-сервере. Я лишь перестал терпеть неуважительное общение со стороны данной группы лиц. Если нужны доказательства - у меня полно доказательств с вашей травлей людей и рейдами серверов.
На официальной странице и в статье лишь указаны мои принципы развития компилятора - попытка достичь производительности C/C++, хотя бы частично. Двигаюсь в этом ключе.
Данный "фрагмент" должен сначала быть доказан.
Знаю. И мой проект - один из проектов для увеличения мной познания в области С++. Как вы видите, фидбек я какой-никакой получаю, и узкие места свои стараюсь исправлять.
Сама "хейтерская" статья скорее основана на личной неприязни (около полугода назад я забанил автора этой статьи за постоянное грубое общение, издевательства и оскорбления в мой адрес и адрес других участников моего Discord-сервера).
При этом же, все перечисленные баги (которые действительно являются багами, а не пример с делением на 0 или хэш-функцией) я пофиксил примерно за час, сразу после выхода статьи.
Сам проект, как я неоднократно подчёркивал, является сугубо личным и лишь попыткой создания самодельного компилятора, но спасибо за поддержку.
Не совсем понимаю, кто оставил вышестоящий комментарий (Only_god_can_judge_me), но цель моего проекта - создание самодельного компилятора. Никакой речи о популярности, или, тем более, замены других языков не идёт.
Сравнение с "BolgenOS" некорректно - для меня Rave что-то вроде хобби-проекта, которым я занимаюсь в свободное время.
Про "ЧСВ" не совсем понимаю. Так как это мой личный проект, то, по-моему, лишь я могу решать, что добавлять в него, а что нет? По возможности прислушиваюсь к дельным советам, в основном по фиксу багов.
"Объективная критика" не должна состоять из насмешек, издевательств и оскорблений. Я всегда открыт к критике, и даже сейчас, после выхода данной статьи, продолжаю улучшать свой личный проект.
При этом же, хочу отметить, что проект я развиваю в одиночку. Если автор комментария прав, то вокруг меня должна быть команда разработчиков, так? Ну, как минимум статистика GitHub говорит обратное. Качество кода (так как я ещё в процессе изучения С++ - уже около полутора лет) соответствующее, но рабочее.
А зачем спамить своим комментарием сразу в несколько веток - уже иной вопрос)
Я разрабатывал свой парсер сам, без различных утилит. Однако другим такой подход может показаться сложнее, чем те подходы, которые описаны в этой статье.
Спасибо, что высказали мне свою точку зрения на синтаксис.
Акцент был сделан на то, что эти операторы и конструкции итак находятся в "обороте", и пользователям будет легче принять и использовать новый функционал.
import, как я считаю, не должен давать излишней функциональности. Все, что требуется пользователю - импортирования файлов проекта, файлов библиотек и std. И import с этой задачей справляется. А насчёт кавычек - они были выбраны для той же удобности людям, которые привыкли писать на С/С++.
';' в конце строки находится для отладки компилятором и некоторых... "трюков" в парсинге языка.
По поводу константности - присутствует "const(type)":
const(char)* str = "Hi!";
Про самосборку - не весь нужный функционал имеется, но постепенно будем добавлять чего не хватает.
Нет, на данный момент компилятор не self-hosted, но это в ближайших планах.
Примеры есть в данной статье, а также в GitHub-репозитории. На данный момент их там мало, так что я напишу вас интересующие:
struct Bow {
float data;
}
struct Foo {
void method {
data = 0.0;
}
void method(int a) {
data = cast(float)a;
}
}
void main {
Foo foo;
foo.method();
foo.method(10);
}
Наследование сейчас реализовано, скажем так, не лучшим образом, но для простого предотвращения копирования элементов структуры в другие структуры множество раз руками вполне сойдёт.
Про отладку ошибок - примеры приведены в статье. Но вкратце - itop/ptoi проверяются на нулевое значение, а std::error<type> позволяет удобно получать результат выполнения функции с возможностью отследить возможные ошибки.
Про ABI - сейчас оно плохо задокументировано, каюсь.
Но в целом, если вам нужно, скажем, импортировать функцию из С-библиотеки, вы можете использовать linkname:
extern(linkname: "foo") void raveFoo();
Таким же способом вы можете вручную задавать выходные имена для функций, чтобы улучшить взаимодействие с ними из других языков программирования.
По поводу решения проблем из C/C++ - в данной области до сих пор ведётся активная разработка, так что точно сказать не могу. Но в целом, акцент ведётся на улучшенную безопасность работы с памятью и указателями - тому пример структура SafePtr(которая недавно была переведена в std/memutil):
import <std/memutil>
void main {
auto ptr = SafePtr<int>(10);
int[10] array;
ptr.pointer = &array;
}
Работа с SafePtr позволяет частично облегчить отладку ошибок, связанных с попыткой доступа за грани указателя.
"itop"/"ptoi" являются встроенными инструкциями, которые соответствуют тем же инструкциям в LLVM. Для удобства, "itop" принимает первый аргумент в виде типа, чтобы не пришлось лишний раз прописывать "cast(type)".
Как вы верно подметили - try является исключением из правила "переменная объявленная внутри блока, видна только там". В основном, он используется для тех мест, где не так важна пользовательская отладка ошибок - в таком случае, пользователь может поручить компилятору автоматически проверять вызовы таких функций на ошибку.
Сам пользователь может собственноручно проверить, есть ли ошибка при вызове функции через catch:
import <std/error> <std/io>
std::error<int> foo => std::error<int>(0,"Error!\n",100);
void main {
std::error<int> result = foo();
result.catch();
result.catch(void(char* msg, int code) {
std::println(msg,", code: ",code);
});
}
Спасибо. Желаю тебе тоже дальнейших успехов в программировании!
Спасибо, позже все проанализирую.
Данный участник неуважительно себя вёл довольно продолжительное время, что можно увидеть по его манере речи как минимум. Я решил, что в ближайшее время перестану терпеть любые подобные выходки, даже если эти люди иногда говорят полезные вещи.
Багом, в данном случае, является то, что не запланировано. Деление на ноль с самого начала должно было приводить к неопределённому поведению.
Я ничего не оправдывал и не оправдываю. Я лишь делаю свой личный проект, не претендующий на значимость в текущей системе. Разумеется, лишь я решаю, как его обновлять.
Мне была показана лишь малая часть багов. Весь язык сейчас находится в постоянном изменении, что можно видеть по коммитам. Ближе к релизу 1.20 постараюсь стабилизировать состояние.
На будущее: не прикрывайся объективной критикой, как ты делал это на Discord-сервере. Я лишь перестал терпеть неуважительное общение со стороны данной группы лиц. Если нужны доказательства - у меня полно доказательств с вашей травлей людей и рейдами серверов.
Спасибо за тёплые слова. Вам также желаю хорошего кода и нового опыта :^
На официальной странице и в статье лишь указаны мои принципы развития компилятора - попытка достичь производительности C/C++, хотя бы частично. Двигаюсь в этом ключе.
Данный "фрагмент" должен сначала быть доказан.
Знаю. И мой проект - один из проектов для увеличения мной познания в области С++. Как вы видите, фидбек я какой-никакой получаю, и узкие места свои стараюсь исправлять.
Спасибо за ваши комментарии.
Привет. Спасибо за комментарий.
Я не читал книги по LLVM, лишь документацию и некоторые презентации.
Насчёт "подмножества С++" - был бы рад услышать ваши возможные идеи по поводу улучшения языка в более лучшую сторону.
Спасибо за комментарий.
Сама "хейтерская" статья скорее основана на личной неприязни (около полугода назад я забанил автора этой статьи за постоянное грубое общение, издевательства и оскорбления в мой адрес и адрес других участников моего Discord-сервера).
При этом же, все перечисленные баги (которые действительно являются багами, а не пример с делением на 0 или хэш-функцией) я пофиксил примерно за час, сразу после выхода статьи.
Сам проект, как я неоднократно подчёркивал, является сугубо личным и лишь попыткой создания самодельного компилятора, но спасибо за поддержку.
Приветствую.
Не совсем понимаю, кто оставил вышестоящий комментарий (Only_god_can_judge_me), но цель моего проекта - создание самодельного компилятора. Никакой речи о популярности, или, тем более, замены других языков не идёт.
Сравнение с "BolgenOS" некорректно - для меня Rave что-то вроде хобби-проекта, которым я занимаюсь в свободное время.
Про "ЧСВ" не совсем понимаю. Так как это мой личный проект, то, по-моему, лишь я могу решать, что добавлять в него, а что нет? По возможности прислушиваюсь к дельным советам, в основном по фиксу багов.
"Объективная критика" не должна состоять из насмешек, издевательств и оскорблений. Я всегда открыт к критике, и даже сейчас, после выхода данной статьи, продолжаю улучшать свой личный проект.
При этом же, хочу отметить, что проект я развиваю в одиночку. Если автор комментария прав, то вокруг меня должна быть команда разработчиков, так? Ну, как минимум статистика GitHub говорит обратное. Качество кода (так как я ещё в процессе изучения С++ - уже около полутора лет) соответствующее, но рабочее.
А зачем спамить своим комментарием сразу в несколько веток - уже иной вопрос)
Я разрабатывал свой парсер сам, без различных утилит. Однако другим такой подход может показаться сложнее, чем те подходы, которые описаны в этой статье.
Да, там небольшая опечатка.
Наследование происходит через ':'.
В минимальном виде присутствует.
В таком случае ваше предложение вполне может иметь применение.
Спасибо за идею!
Спасибо, что высказали мне свою точку зрения на синтаксис.
Акцент был сделан на то, что эти операторы и конструкции итак находятся в "обороте", и пользователям будет легче принять и использовать новый функционал.
import, как я считаю, не должен давать излишней функциональности. Все, что требуется пользователю - импортирования файлов проекта, файлов библиотек и std. И import с этой задачей справляется. А насчёт кавычек - они были выбраны для той же удобности людям, которые привыкли писать на С/С++.
';' в конце строки находится для отладки компилятором и некоторых... "трюков" в парсинге языка.
"try" нужен для автоматизации ловли ошибок при вызовах функций с возвращаемым типом std::error<type>.
Как вы хотите сделать это по-умолчанию - я, честно сказать, не понимаю. Возможно, вы имели ввиду переход на полноценные исключения.
По поводу константности - присутствует "const(type)":
Про самосборку - не весь нужный функционал имеется, но постепенно будем добавлять чего не хватает.
Нет, на данный момент компилятор не self-hosted, но это в ближайших планах.
Примеры есть в данной статье, а также в GitHub-репозитории. На данный момент их там мало, так что я напишу вас интересующие:
Наследование сейчас реализовано, скажем так, не лучшим образом, но для простого предотвращения копирования элементов структуры в другие структуры множество раз руками вполне сойдёт.
Про отладку ошибок - примеры приведены в статье. Но вкратце - itop/ptoi проверяются на нулевое значение, а std::error<type> позволяет удобно получать результат выполнения функции с возможностью отследить возможные ошибки.
Про ABI - сейчас оно плохо задокументировано, каюсь.
Но в целом, если вам нужно, скажем, импортировать функцию из С-библиотеки, вы можете использовать linkname:
Таким же способом вы можете вручную задавать выходные имена для функций, чтобы улучшить взаимодействие с ними из других языков программирования.
По поводу решения проблем из C/C++ - в данной области до сих пор ведётся активная разработка, так что точно сказать не могу. Но в целом, акцент ведётся на улучшенную безопасность работы с памятью и указателями - тому пример структура SafePtr(которая недавно была переведена в std/memutil):
Работа с SafePtr позволяет частично облегчить отладку ошибок, связанных с попыткой доступа за грани указателя.
P.S. Насчёт сертификата знаю...(
Если речь идёт в контексте Rave, то массивы по-умолчанию передаются по значению, что автоматически обязывает компилятор проверять типы.
Спасибо за идею, возможно реализую.
"itop"/"ptoi" являются встроенными инструкциями, которые соответствуют тем же инструкциям в LLVM. Для удобства, "itop" принимает первый аргумент в виде типа, чтобы не пришлось лишний раз прописывать "cast(type)".
Как вы верно подметили - try является исключением из правила "переменная объявленная внутри блока, видна только там". В основном, он используется для тех мест, где не так важна пользовательская отладка ошибок - в таком случае, пользователь может поручить компилятору автоматически проверять вызовы таких функций на ошибку.
Сам пользователь может собственноручно проверить, есть ли ошибка при вызове функции через catch: