Тупые вопросы по pure C.

Д - д*бил

Что это за умолчания такие? У меня вот допустим gcc собирает с musl.

Что это за умолчания

man gcc | grep -i libc

man gcc | grep -i musl

Это Open Source. Без финансирования они лет через 10 это запилят, если повезет.

Проверил, в libstdc++ хедер <thread> доступен минимум с 2009-го года (более ранней версии компилятора под рукой нет), т.е. еще до принятия стандарта, а значит дело не в Open Source, а в принципиальном решении, что «скрипач» не нужен, или почти не нужен.

При чем тут асм если речь про Си? Си то почему непереносимый?

Тебя директория arch/ с архитектурно-зависимыми вещами не смущает?

Если ты на жабке напишешь, что у тебя внезапно arch исчезнет?

Если ты на жабке напишешь, что у тебя внезапно arch исчезнет?

Ну как минимум не придется писать свою реализацию атомиков на каждый чих, да.

архитектурно-зависимыми вещами

Даже в ОС на Java или C# без них не обойтись, но непереносимыми эти языки никто не называет.

Кстате а кокое отношение имеет глибц к гцц?

Такое, что gcc не предоставляет свою собственную реализацию libc. А для GNU/Linux стандарт это glibc, и все остальное - ничтожно малые флуктуации.

Даже в ОС на Java или C# без них не обойтись, но непереносимыми эти языки никто не называет.

Ты на Java пишешь архитектурно-зависимый код? Часто? Заметь, тут речь не про ОС-специфичные вещи. Я говорю о такой банальной вещи, как атомарные переменные.

ОС на Java

Ты хотел сказать ОС на ассемблере? http://www.jnode.org/node/2936

У меня это MinGW-w64, дальше что? При этом в райнтайме приложение линкуется с msvcr.

У меня это MinGW-w64, дальше что?

Да ничего, ты точно так же не можешь пользоваться тредами из С11, что gcc/glibc, что с MinGW-w64. В некотором роде это даже можно назвать совместимостью.

Всё же не ясно, чем гцц виноват. Они сразу сказали, что это проблема рантайма.

Я в первом своем сообщении и написал, что проблема в glibc.

К языку стандартная библиотека имеет опосредованное отношение. Для исполнения программы на си хватит наличия стека и boilerplate кода передающий управление в main.

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

Если тебе нужно только описание языка, то читай стандарт. Там всё есть.

Только назвать это жабой можно весьма условно.

Хочешь переносимый, бери java.

На машинах с отличной от IEEE754 FP арифметикой не заработает. А C заработает.

open и clock_gettime не входят в стандарт.

Входят. В POSIX

К языку стандартная библиотека имеет опосредованное отношение. Для исполнения программы на си хватит наличия стека и boilerplate кода передающий управление в main.

Не мешай всё вместе. В hosted-окружении должны быть реализованы все неопциональные хедеры. Во freestanding-окружении программа даже с main() начинать исполняться не обязана.

Кому он нужен при живом pthreads?

Си — непереносимый язык

Ты сделал мой день !

Хочешь переносимый, бери java

Запусти кусок Java на QNX, к примеру.

Я отвечал на вопрос о стандарте С

Кому он нужен при живом pthreads?

Очевидно тем, кто хотел бы писать переносимый (на деле, а не в виде POSIX) код на С.

переносимый (на деле, а не в виде POSIX)

https://www.opengroup.org/austin/papers/posix_faq.html

Q0. What is POSIX? What is POSIX.1? POSIX is a registered trademark of the IEEE.

POSIX is an acronym for Portable Operating System Interface.

Запусти кусок Java на QNX, к примеру.

А в чем проблема? Под QNX есть различные реализации Java.

Под QNX есть различные реализации Java

JAVA for QNX - с тех пор ничего НЕ поменялось.

https://supportforums.blackberry.com/t5/Java-Development/DevCon-update-BB-Jav...

Для изучения С я бы посоветовал изучать сорцы Plan 9.

POSIX is an acronym for Portable Operating System Interface.

Спасибо, кэп, но я же не зря написал «на деле». А на деле есть ОС, где клали с прибором на POSIX. И имеют на это право.

есть ОС, где клали с прибором на POSIX

Так значит проблема непереносимости не в коде, а в этих ОС.

вон возьми lua. собирается ваще всем даже турбо С 90 года.

Посчитай количество ifdef там.

Я посчитал, у меня ноль вышло.

┌ home :: ~/tmp :: rm lua-5.3.3.tar.gz
└ d_a % wget https://www.lua.org/ftp/lua-5.3.3.tar.gz
--2016-11-10 20:59:15--  https://www.lua.org/ftp/lua-5.3.3.tar.gz
Распознаётся www.lua.org (www.lua.org)... 148.251.24.173, 2a01:4f8:201:620f::2001
Подключение к www.lua.org (www.lua.org)|148.251.24.173|:443... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа... 200 OK
Длина: 294290 (287K) [application/gzip]
Сохранение в: «lua-5.3.3.tar.gz»

100%[===================================================================================================================================================================================================>] 294 290     1,15MB/s   за 0,2s   

2016-11-10 20:59:17 (1,15 MB/s) - «lua-5.3.3.tar.gz» сохранён [294290/294290]

┌ home :: ~/tmp :: wget https://www.lua.org/ftp/lua-5.3.3.tar.gz
└ d_a % tar xf lua-5.3.3.tar.gz 
┌ home :: ~/tmp :: tar xf lua-5.3.3.tar.gz
└ d_a % cd lua-5.3.3/
┌ home :: ~/tmp/lua-5.3.3 :: cd lua-5.3.3/
└ d_a % grep -iR '#ifdef' src/
┌ home :: ~/tmp/lua-5.3.3 :: grep -iR '#ifdef' src/ (rc = 1)
└ d_a % grep -iR '#ifndef' src/
src/lctype.h:#ifndef lctype_h
src/ltm.h:#ifndef ltm_h
src/lobject.h:#ifndef lobject_h
src/lopcodes.h:#ifndef lopcodes_h
src/llimits.h:#ifndef llimits_h
src/luaconf.h:#ifndef luaconf_h
src/lgc.h:#ifndef lgc_h
src/lstate.h:#ifndef lstate_h
src/lcode.h:#ifndef lcode_h
src/llex.h:#ifndef llex_h
src/ldebug.h:#ifndef ldebug_h
src/lua.h:#ifndef lua_h
src/lauxlib.h:#ifndef lauxlib_h
src/lualib.h:#ifndef lualib_h
src/lfunc.h:#ifndef lfunc_h
src/ltable.h:#ifndef ltable_h
src/lstring.h:#ifndef lstring_h
src/lapi.h:#ifndef lapi_h
src/lparser.h:#ifndef lparser_h
src/lmem.h:#ifndef lmem_h
src/lundump.h:#ifndef lundump_h
src/lprefix.h:#ifndef lprefix_h
src/lvm.h:#ifndef lvm_h
src/ldo.h:#ifndef ldo_h
src/lzio.h:#ifndef lzio_h
┌ home :: ~/tmp/lua-5.3.3 :: grep -iR '#ifndef' src/
└ d_a % 

Без нотариального штампа пруфы не принимаются.

Так значит проблема непереносимости не в коде, а в этих ОС.

Треды в стандарте есть? Есть. Пользоваться ими можно (в том числе на ОС с pthreads)? Нет, хотя в стандарте они уже давно. Виноваты ли в этом ОС без поддержки POSIX? Конечно, нет. Т.е. пользуясь исключительно стандартом языка можно написать код, который почти нигде не соберется. Просто эталон переносимости.

Ваш луа не луа ^_~

Треды в стандарте есть? Есть.

И их поддержка опциональна.

Ищи #if defined и #if !defined

Да, так нашлося несколько LUA_USE_POSIX, LUA_USE_C89 и __GNUC__, значит я ошибся и не ноль.

И их поддержка опциональна.

Как и в POSIX.

И их поддержка опциональна.

Как и в POSIX.

Хм. А пруфы есть какие-то? А то я пока нашёл:

The following symbolic constants shall be defined by the implementation as follows:

Symbolic constants defined with the value 200809L:

_POSIX_ASYNCHRONOUS_IO
_POSIX_BARRIERS
_POSIX_CLOCK_SELECTION
_POSIX_MAPPED_FILES
_POSIX_MEMORY_PROTECTION
_POSIX_READER_WRITER_LOCKS
_POSIX_REALTIME_SIGNALS
_POSIX_SEMAPHORES
_POSIX_SPIN_LOCKS
_POSIX_THREAD_SAFE_FUNCTIONS
_POSIX_THREADS           <------
_POSIX_TIMEOUTS
_POSIX_TIMERS
_POSIX2_C_BIND

Это всё shall, не may.

Оно распространяется в составе ОраклЖдк.

Хм. А пруфы есть какие-то? А то я пока нашёл:
200809L

Сейчас, да, вероятно обязательно, а раньше было расширением. И учитывая, что все пишут на C89 и С99, то, если брать POSIX той же протухлости, то там тредов или не было, или были необязательны.

И учитывая, что все пишут на C89 и С99, то, если брать POSIX той же протухлости, то там тредов или не было, или были необязательны.

В C89 и C99 их же не было точно.

Разговор начался с C11. Ну и POSIX надо брать «той же протухлости».

Короче, для соответствия C11 треды реализовывать не обязательно. И никто не реализует, т.к. никому не нужно.

Разговор начался с C11. Ну и POSIX надо брать «той же протухлости».

Если отойти от темы тредов, то там ситуация еще хуже чем с С11. Есть хоть одна ОС, где заявлена полная поддержка POSIX 2008?

на нескольких платформах

на всех платформах поддерживаемых языком/инструментарием

детка, а ты понимаешь, что такое переносимость? так вот: переносимость - это возможность скомпилировать и запустить код на определённой архитектуре. а венда - это просто ДРУГАЯ программа, детка. и о «переносимости» одной программы внутри другой программы говорить как-то глупо, не правда ли?

ну-ну, тешьте себя сказочками. только не надо мне эту пургу рассказывать. жабка ваша - это её окружение, которое жрёт ресурсы. без него она - труп. и ни на какой, пардон, «сим-карте» запустить эту халабуду не получится.

переносимость - это возможность скомпилировать и запустить код на определённой архитектуре

Сама придумала?

Portability in high-level computer programming is the usability of the same software in different environments.

https://en.wikipedia.org/wiki/Software_portability

Кстати, под твоё определение C паршиво подходит. Про атомики и треды выше уже сказали.

http://www.oracle.com/technetwork/java/embedded/javacard/overview/index.html

Жаба? Жаба! Работает на сим-карте? Работает!

Однако тем не менее, там есть куча кода, который для всех платформ одинаков.

Что мешает программисту на Си использовать какую-нибудь библиотеку, которая берёт на себя все специфичные вещи?

Взять тот же SDL. Можно написать игрушку, исходники которой менять не придётся, хоть ты компилируешь под винду, хоть под Linux, хоть по Mac OS. Отличаться будут только команды компиляции (и то какой-нибудь CMake упростит задачу портирования, а в простых случаях и вовсе позволит написать универсальный сценарий сборки), но это явно не часть исходного кода на Си (да и портабельность у разных систем сборки разная).

И да, в какой-нибудь Java тоже по факту портабельность осуществляется с помощью библиотек. Хоть интерфейс создания тех же окошек может быть и одинаков, но на винде в реальности будет дёргаться WinAPI, а под Linux - иксы. Чем кросс-платформенные библиотеки для Си (SDL, GTK) принципиально отличаются?