LINUX.ORG.RU

История изменений

Исправление Moisha_Liberman, (текущая версия) :

бестолковый и неугомонный, давайте я Вас ещё в дерьмецо ткну. Мне не сложно, да и сборка идёт долгая.

Итак.

Я ему про рантайм, он мне про стандарт.

Хмм… Т.е., батенька, Вы в глазоньки изволите долбиться, как я правильно понимаю? =))) Я же Вам по-русски написал:

Если Вы не понимаете что сказанное в стандарте должно поддерживаться в рантайме в более-менее полном объёме, то это уже значит что мне нужно заниматься Вашим пост-ГПТУшным образованием.

Судя по Вашим же цитатам, вроде видели. А выводов не, сделать не смогли?

Вот сейчас под руками аналог уже упомянутого в треде сс1310, правда, сс1352. Там я не могу глянуть, т.к. там просто нет отдельного С++ рантайма.

Давайте глянем на х86_64. Система тщательно и со вкусом оптимизирована по ключам компиляции и линковки. Так что, откосить тут не получится. У нас стандартными runtime libraries будут glibc и libstdc++.

Итак, для начала я напишу два хеловорлда, чтобы максимально точно понять какие либы у нас используются. Не, написать их нужно, т.к. в стандартной либе С++ будут использоваться функции из стандартной С-либы. Проверим так ли это. =)))

Чтобы любой заинтересованный мог повторить то же самое, я всё буду делать по шагам.

Итак, С-вариант:

/* gcc 1.c -o 1 */
#include <stdio.h>

int main() {
	printf("%s\n", "Hi, anonymous woodpecker!");
	return 0;
}

C++ вариант:

/* g++ 2.cpp -o 2 */
#include <iostream>

using namespace std;

int main() { 
    cout << "Hi, anonymous woodpecker! =)))" << endl;
    return 0;
}

Теперь смотрим ldd 1:

        linux-vdso.so.1 (0x00007ffff4bc7000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f94545e5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f94547d2000)

Далее смотрим ldd 2:

        linux-vdso.so.1 (0x00007ffd633d4000)
	libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so.6 (0x00007f68f7068000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f68f6f2f000)
	libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libgcc_s.so.1 (0x00007f68f6f14000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f68f6d5a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f68f72b0000)

С какого перепою здесь болтаются вызовы сишного рантайма? Да с такого, что плюсовый рантайм, как я и сказал выше, на нём и основан. И его поэтому использует.

Но мы же хотели на размер рантайма посмотреть? Извольте:

C++:

-rwxr-xr-x 1 root root 2165312 июл 30 14:49 libstdc++.so.6.0.29

C:

-rwxr-xr-x 1 root root 1794208 авг 18 22:39 libc-2.33.so

То есть, даже при условии того, что С++ рантайм использует С-рантайм, один пень размеры плюсового рантайма больше. Какие были бы размеры, если бы плюсовый рантайм жил сам по себе и без сишного, я Вам сразу могу сказать – приплюсуйте к плюсовому сишный и возрадуйтесь. Вот эта разница и есть «цена» Вашего плюсового стандарта. Потому как системные вызовы в Linux можно и на С спокойно сделать, а не как на С++ через анус.

Я могу даже больше сказать – именно из-за размеров сишного рантайма и появились такие альтернативные glibc проекты как newlib, uClibc, musl. Про плюсовый рантайм даже и не говорят, заметьте. Ну, по крайней мере, в трезвом уме и здравой памяти.

На ARM смотреть соотношения будем? =)))

сигналов, то и нетути.

Каких там сигналов нетути, бестолковый Вы мой? =))) Если прошивка написана даже с заменой glibc, то сигналы там будут. Если там использована иная библиотека и ясно сказано что она POSIX-compatible, то сигналы там тоже будут. Вот исходник от TI для сс13*/сс26*. Реализация сигналов в той же TI-RTOS отличается и от Linux-реализации и от FreeRTOS-реализации. Это просто у Вас мозгов нетути чтобы это понять.

Дальше.

Также стандарт требует что б функция printf умела форматировать в том числе и float/double. Cознавайся мойша, не выключаешь поддержку форматирования плавучки?

Скажите, Вы дурак от Бога или Вас таким жизнь сделала? =))) Не, ну серьёзно? А это ни чего что на контроллере считать с плавающей точкой что-либо, это махом быть уволенным? Ну просто потому, что это непроизводительный расход крайне ограниченных вычислительных ресурсов? Да и аппаратной поддержки операций с плавающей запятой в проце может не оказаться и тогда придётся считать всё в soft float. Нормально? Вы вообще в своём уме? =))) Может, Вам санитаров вызвать? Суровых и с галоперидолом?

Как Вас беспокоит наличие math.h, если в стандартной библиотеке реализация функций для работы с плавающей запятой есть и её ни кто никуда не убирал? Просто ею не пользуются. Ну, стараются не пользоваться, если только не дол… (не Вы лично) автор прошивки.

Вот например, поддержка операций с плавающей запятой для musl. Кто её отключает? Зачем? Вы где такой код видели, что у Вас родился такой идиотский вопрос? =)))

Из стандартной либы ничего не убирается. Это не эксепшоны из С++ выкидывать. =)))

P.S. Вы точно имеете какое-то отношение к программированию встраиваемых систем? А то у нас тут уже был один пОциент. Посмешила, да… =)))

Исходная версия Moisha_Liberman, :

Ну, коль скоро Вы такой...

юестолковый и неугомонный, давайте я Вас ещё в дерьмецо ткну. Мне не сложно, да и сборка идёт долгая.

Итак.

Я ему про рантайм, он мне про стандарт.

Хмм… Т.е., батенька, Вы в глазоньки изволите долбиться, как я правильно понимаю? =))) Я же Вам по-русски написал:

Если Вы не понимаете что сказанное в стандарте должно поддерживаться в рантайме в более-менее полном объёме, то это уже значит что мне нужно заниматься Вашим пост-ГПТУшным образованием.

Судя по Вашим же цитатам, вроде видели. А выводов не, сделать не смогли?

Вот сейчас под руками аналог уже упомянутого в треде сс1310, правда, сс1352. Там я не могу глянуть, т.к. там просто нет отдельного С++ рантайма.

Давайте глянем на х86_64. Система тщательно и со вкусом оптимизирована по ключам компиляции и линковки. Так что, откосить тут не получится. У нас стандартными runtime libraries будут glibc и libstdc++.

Итак, для начала я напишу два хеловорлда, чтобы максимально точно понять какие либы у нас используются. Не, написать их нужно, т.к. в стандартной либе С++ будут использоваться функции из стандартной С-либы. Проверим так ли это. =)))

Чтобы любой заинтересованный мог повторить то же самое, я всё буду делать по шагам.

Итак, С-вариант:

/* gcc 1.c -o 1 */
#include <stdio.h>

int main() {
	printf("%s\n", "Hi, anonymous woodpecker!");
	return 0;
}

C++ вариант:

/* g++ 2.cpp -o 2 */
#include <iostream>

using namespace std;

int main() { 
    cout << "Hi, anonymous woodpecker! =)))" << endl;
    return 0;
}

Теперь смотрим ldd 1:

        linux-vdso.so.1 (0x00007ffff4bc7000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f94545e5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f94547d2000)

Далее смотрим ldd 2:

        linux-vdso.so.1 (0x00007ffd633d4000)
	libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so.6 (0x00007f68f7068000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f68f6f2f000)
	libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libgcc_s.so.1 (0x00007f68f6f14000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f68f6d5a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f68f72b0000)

С какого перепою здесь болтаются вызовы сишного рантайма? Да с такого, что плюсовый рантайм, как я и сказал выше, на нём и основан. И его поэтому использует.

Но мы же хотели на размер рантайма посмотреть? Извольте:

C++:

-rwxr-xr-x 1 root root 2165312 июл 30 14:49 libstdc++.so.6.0.29

C:

-rwxr-xr-x 1 root root 1794208 авг 18 22:39 libc-2.33.so

То есть, даже при условии того, что С++ рантайм использует С-рантайм, один пень размеры плюсового рантайма больше. Какие были бы размеры, если бы плюсовый рантайм жил сам по себе и без сишного, я Вам сразу могу сказать – приплюсуйте к плюсовому сишный и возрадуйтесь. Вот эта разница и есть «цена» Вашего плюсового стандарта. Потому как системные вызовы в Linux можно и на С спокойно сделать, а не как на С++ через анус.

Я могу даже больше сказать – именно из-за размеров сишного рантайма и появились такие альтернативные glibc проекты как newlib, uClibc, musl. Про плюсовый рантайм даже и не говорят, заметьте. Ну, по крайней мере, в трезвом уме и здравой памяти.

На ARM смотреть соотношения будем? =)))

сигналов, то и нетути.

Каких там сигналов нетути, бестолковый Вы мой? =))) Если прошивка написана даже с заменой glibc, то сигналы там будут. Если там использована иная библиотека и ясно сказано что она POSIX-compatible, то сигналы там тоже будут. Вот исходник от TI для сс13*/сс26*. Реализация сигналов в той же TI-RTOS отличается и от Linux-реализации и от FreeRTOS-реализации. Это просто у Вас мозгов нетути чтобы это понять.

Дальше.

Также стандарт требует что б функция printf умела форматировать в том числе и float/double. Cознавайся мойша, не выключаешь поддержку форматирования плавучки?

Скажите, Вы дурак от Бога или Вас таким жизнь сделала? =))) Не, ну серьёзно? А это ни чего что на контроллере считать с плавающей точкой что-либо, это махом быть уволенным? Ну просто потому, что это непроизводительный расход крайне ограниченных вычислительных ресурсов? Да и аппаратной поддержки операций с плавающей запятой в проце может не оказаться и тогда придётся считать всё в soft float. Нормально? Вы вообще в своём уме? =))) Может, Вам санитаров вызвать? Суровых и с галоперидолом?

Как Вас беспокоит наличие math.h, если в стандартной библиотеке реализация функций для работы с плавающей запятой есть и её ни кто никуда не убирал? Просто ею не пользуются. Ну, стараются не пользоваться, если только не дол… (не Вы лично) автор прошивки.

Вот например, поддержка операций с плавающей запятой для musl. Кто её отключает? Зачем? Вы где такой код видели, что у Вас родился такой идиотский вопрос? =)))

Из стандартной либы ничего не убирается. Это не эксепшоны из С++ выкидывать. =)))