BD
есть еще вариант что определенные классы в компиле используют специфические аллокаторы для скорости
Size: a a a
2021 January 19
BD
и просто их маллочить ататат
A
Вот да, даже общая часть
gcc/c-family/ частично на плюсах написана
И по стандарту он все g++ собирает
Есть ли возможность писать на чистом С или такая возможность только в linux kernel разработке осталась?
gcc/c-family/ частично на плюсах написана
И по стандарту он все g++ собирает
Есть ли возможность писать на чистом С или такая возможность только в linux kernel разработке осталась?
Кстати, когда писал свой фронт к gcc он был написан на чистой сишечке и с использованием malloc'ов :) Но там соответственно не инклюдились файлы gcc там где не надо (во flex/bison)
BD
Кстати, когда писал свой фронт к gcc он был написан на чистой сишечке и с использованием malloc'ов :) Но там соответственно не инклюдились файлы gcc там где не надо (во flex/bison)
а для flex/bison там разрешено маллочить )
BD
оно редиректит на xmalloc
BD
кстати может быть в libiberty написано за что там xmalloc можно а malloc нет
JT
Кстати, когда писал свой фронт к gcc он был написан на чистой сишечке и с использованием malloc'ов :) Но там соответственно не инклюдились файлы gcc там где не надо (во flex/bison)
Просто у вас в второй статье
Используется
cgraph_node::finalize_function()
Вроде как есть чисто С альтернатива
cgraph_finalize_function() упомянутая в parse pass (gcc internals)
Но у меня она не заработала(
Используется
cgraph_node::finalize_function()
Вроде как есть чисто С альтернатива
cgraph_finalize_function() упомянутая в parse pass (gcc internals)
Но у меня она не заработала(
JT
Просто у вас в второй статье
Используется
cgraph_node::finalize_function()
Вроде как есть чисто С альтернатива
cgraph_finalize_function() упомянутая в parse pass (gcc internals)
Но у меня она не заработала(
Используется
cgraph_node::finalize_function()
Вроде как есть чисто С альтернатива
cgraph_finalize_function() упомянутая в parse pass (gcc internals)
Но у меня она не заработала(
Собсна в попытках ее завести я и выяснил что
cgraph надо после tree инклюдить
cgraph надо после tree инклюдить
A
Просто у вас в второй статье
Используется
cgraph_node::finalize_function()
Вроде как есть чисто С альтернатива
cgraph_finalize_function() упомянутая в parse pass (gcc internals)
Но у меня она не заработала(
Используется
cgraph_node::finalize_function()
Вроде как есть чисто С альтернатива
cgraph_finalize_function() упомянутая в parse pass (gcc internals)
Но у меня она не заработала(
Часть, которая взаимодействует непосредственно с гцц в любом случае будет плюсовой, без вариантов. Просто можно максимально её изолировать от парсера.
А с инклюдниками - да, было бы очень смешно если бы не было так грустно. В этом плане у меня дико бомбило от того как всё в гцц сделано
А с инклюдниками - да, было бы очень смешно если бы не было так грустно. В этом плане у меня дико бомбило от того как всё в гцц сделано
JT
А в llvm - та же картина или там получше?
BD
А в llvm - та же картина или там получше?
В llvm картина совсем другая
KR
Слова не мальчика, но Джона Лакоса, но не все и не всегда так делают, могут делать или даже хотят делать.
«Ибо программист не должен писать программы с ошибками, а должен писать их писать без ошибок!»
Меня натурально начало трясти, когда я узнал, что они вставили UB в класс даты.
Меня натурально начало трясти, когда я узнал, что они вставили UB в класс даты.
DP
что думаете про некий протоязык компилятора, который просто дает полный доступ ко всему, не ограничивая возможности. и там уже пользователь может выбрать что-то типа разных парадигм, чего-то типа языков, ну или написать свое
т.е. изначально компилятор обладает самыми минимальными возможностями, типа знает опкоды, умеет выделять память, взаимодействовать с ОС, но сам код типа обьектов и типов - не определен еще
т.е. изначально компилятор обладает самыми минимальными возможностями, типа знает опкоды, умеет выделять память, взаимодействовать с ОС, но сам код типа обьектов и типов - не определен еще
BD
что думаете про некий протоязык компилятора, который просто дает полный доступ ко всему, не ограничивая возможности. и там уже пользователь может выбрать что-то типа разных парадигм, чего-то типа языков, ну или написать свое
т.е. изначально компилятор обладает самыми минимальными возможностями, типа знает опкоды, умеет выделять память, взаимодействовать с ОС, но сам код типа обьектов и типов - не определен еще
т.е. изначально компилятор обладает самыми минимальными возможностями, типа знает опкоды, умеет выделять память, взаимодействовать с ОС, но сам код типа обьектов и типов - не определен еще
это называется libc
BD
установлено в 99,999999% имеющихся систем
DP
это называется libc
ну не совсем. Си все же имеет определенные типы, способы работать с функциями, массивами
но да, это шаг в этом направлении
но да, это шаг в этом направлении
A
что думаете про некий протоязык компилятора, который просто дает полный доступ ко всему, не ограничивая возможности. и там уже пользователь может выбрать что-то типа разных парадигм, чего-то типа языков, ну или написать свое
т.е. изначально компилятор обладает самыми минимальными возможностями, типа знает опкоды, умеет выделять память, взаимодействовать с ОС, но сам код типа обьектов и типов - не определен еще
т.е. изначально компилятор обладает самыми минимальными возможностями, типа знает опкоды, умеет выделять память, взаимодействовать с ОС, но сам код типа обьектов и типов - не определен еще
Для чего? Кажется в большинстве случаев пользователь хочет решить конкретную задачу, а не писать язык/библиотеку/етс для ее решения
DP
ну и конкретно про libc - почему оно не умеет включать только нужные функции? это ведь можно сделать
DP
Для чего? Кажется в большинстве случаев пользователь хочет решить конкретную задачу, а не писать язык/библиотеку/етс для ее решения
ну для этого и есть. типа возможности использовать (почти) любой найденный код. после включения модуля для анализа кода с этого языка
BD
ну и конкретно про libc - почему оно не умеет включать только нужные функции? это ведь можно сделать
умеет, почему же не умеет