История изменений
Исправление
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. Кто её отключает? Зачем? Вы где такой код видели, что у Вас родился такой идиотский вопрос? =)))
Из стандартной либы ничего не убирается. Это не эксепшоны из С++ выкидывать. =)))