соответствие iso стандарту

Любые обсуждения, не нарушающие правил форума.

Модератор: Модераторы

Сообщение STAKANOV » 07.11.2005 23:33:03

Возникает зависимость от версии либц. Программа созданная на одной системе
не работает на другой. Это ужас. Да юниксы на С очень завязаны

Они на нем написаны. Насчет зависимости не уверен - не важно использует программа libc или нет, всеравно ее придется отдельно собрать под FreeBSD, Linux и тп. Но вот вызовы (сами функции) в libc стандартны.

Да и размер этой библиотеки всё время растёт, достигая десятков мегабайт
(если уже не сотен).

%ls -l /lib/
...
-r--r--r-- 1 root wheel 884716 20 окт 10:04 libc.so.5
...
С другой стороны почему бы не иметь возможность написать программу,
которая сможет работать с одним только ядром ?

Это путь обртаный кроссплатформенности. Вызов int80 во FreeBSD и Linux например отличается способом передачи аргументов. А вот вызов функции из (g)libc в обоих случаях будет одинаковый.

В части надёжности, функции на Паскале будут работать не хуже, чем на С.
Поскольку они самые часто используемые, то надёжность будет. А в
скорости будет скорее всего выигрыш.

К сожалению сейчас мы имеем прямо противоположную тенденцию :( В своем стремелении к кроссплатформенности разработчики FPC жертвуют эффективностью и усложняют код. Если заглянишь в некотрые исходники, то увидишь там как одна функция всеголишь вызывает другую функцию и тд. Такой вот принцип матрешки. Где тут выйгрыш в скорости? А уж о багах возникающих на этом пути и говорить не приходится.

Независимость от главных С библиотек и особенно от либц, даст большой
плюс ФП.
Только если это будет целью разарботчиков, а у них похоже такой цели нет.
Аватара пользователя
STAKANOV
энтузиаст
 
Сообщения: 1069
Зарегистрирован: 14.05.2006 21:26:24
Откуда: Зеленоград

Сообщение Nikolay » 08.11.2005 09:33:36

Да, просто поставить галочку в настройках компилятора, мол ANSI Паскаль. И я уверен, что ВСЕ (!) первым делом будут лезть туда, чтобы убедится, что галочка снята... Зато, можно будет сказать: "Мы полностью соответствуем стандартам!" В Builder C++ так и сделали.
Nikolay
 

Сообщение pda » 08.11.2005 16:18:18

По поводу зависимости от внешних библиотек и т.д. Тут "недавно" вышла ветка gcc 4.0, в которую добавили новые механизмы оптимизации, типа автоматической векторизации и т.д... Так вот, пока её ещё отлаживают, думаю, а никто не встречал кодогенератор для FPC, стыкующийся с gcc? :rolleyes:
Аватара пользователя
pda
постоялец
 
Сообщения: 303
Зарегистрирован: 27.05.2005 19:59:53

Сообщение Иван Шихалев » 09.11.2005 01:11:52

никто не встречал кодогенератор для FPC, стыкующийся с gcc?

Есть GPC. У FPC другие задачи.
Аватара пользователя
Иван Шихалев
энтузиаст
 
Сообщения: 1138
Зарегистрирован: 15.05.2006 11:26:13
Откуда: Екатеринбург

Сообщение pda » 09.11.2005 02:17:14

Ага, только на нём FPC/Delphi RTL не соберёшь... ;-)
Аватара пользователя
pda
постоялец
 
Сообщения: 303
Зарегистрирован: 27.05.2005 19:59:53

Сообщение Иван Шихалев » 09.11.2005 03:46:45

Тут уж надо выбирать: или FPC и кроссплатформенность, или GCC, libc и UNIX-way...
Аватара пользователя
Иван Шихалев
энтузиаст
 
Сообщения: 1138
Зарегистрирован: 15.05.2006 11:26:13
Откуда: Екатеринбург

Сообщение noch » 09.11.2005 12:18:15

STAKANOV писал(а): Работа напрямую с ядром хороша только для там где мы ограничены аппратными ресурсами (встраевыемые системы и тп). Кто-нибудь видел юниксоподобную ОС без (G)LIBC ?

Я!
Я видел!
Я таки загрузочныуе диски себе собираю ;)
И на них ставлю программы на fpc написанные ;)
И они работают без libc ;)
Аватара пользователя
noch
постоялец
 
Сообщения: 145
Зарегистрирован: 07.06.2005 09:45:49
Откуда: Armenia

Пред.

Вернуться в Потрепаться

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 23

Рейтинг@Mail.ru