caxapa.ru :: [C18, C2x] 2 года до C21, судя по всему.

Evgeny_CD^{Архитектор} (13.03.2019 02:29, просмотров: 57908)

[C18, C2x] 2 года до C21, судя по всему. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf
1. C18 принят. Багфикс https://www.linux. …s/development/14646083 https://en.wikiped …8_(C_standard_revision) Баги в C11 http://www.open-st …g14/www/docs/n2244.htm 2. C21 Обзор подходов http://www.open-st …g14/www/docs/n2021.htm Общее https://www.reddit …ion_of_the_c_standard/ https://www.infoq. …11/c2x-next-c-standard Нюансы https://gustedt.wo …ss.com/2018/11/12/c2x/ Первый драфт - можно начинать изучать :) ->

Ответить

- Си - сосёт! Фортран форева! - Kpoк(09.04.2021 22:38, ссылка)
  - Все фигня! ASM + 1.16% - вот это я понимаю! :) - Evgeny_CD(10.04.2021 00:15)
    - А что это за процент? - Kpoк(10.04.2021 00:21)
      - Относительного роста популярности. Выше - только питон. - Evgeny_CD(10.04.2021 01:24)
- [C23] оно будет называться. Август 2021 - завершение потока креативных идей. Октябрь 2022 - итоговое голосование. Летом 2023 опубликуют финальный документ. Evgeny_CD(07.04.2021 23:03 - 08.04.2021 01:17, ссылка)
  - #embed принят в C23 Evgeny_CD(1 знак., 08.12.2022 16:52, ссылка)
  - Драфт от 3.09.2022 Evgeny_CD(1 знак., 08.12.2022 16:28, ссылка)
  - Обзор фич C23 Evgeny_CD(1 знак., 08.12.2022 16:20, ссылка)
    - Спасибо. Там прекрасное руководство по саботажу от ЦРУ. =AlexD=(1 знак., 08.12.2022 16:55, картинка)
      - Чего сразу ЦРУ? Похоже на правила жизни обыкновенного бюрократа. - SciFi(08.12.2022 19:15)
        
        мапед не мой )) - =AlexD=(08.12.2022 20:25)
      - +1 - Evgeny_CD(08.12.2022 17:06)
  - Фичи C23 Evgeny_CD(1 знак., 17.07.2022 06:29, ссылка)
  - Текущий драфт Evgeny_CD(1 знак., 01.12.2021 17:09, ссылка)
    - За всякие _Imaginary - сжигать надо. - LightElf(01.12.2021 17:19)
  - Текущее расписание Evgeny_CD(1 знак., 01.12.2021 17:08, ссылка)
  - Примеры дискуссий на их сборищах Evgeny_CD(07.04.2021 23:24, ссылка)
    - "... И когда они займутся чисткой трамвайных путей - прямым своим делом, разруха изчезнет сама собой" @ПП :-) - il-2(08.04.2021 05:29)
  - [C23 digit separators] - так называется одна из фич свежего SDCC 4.1.0. Что-то типа 0x0000'FFFF'FFFF'0000. В обсуждение приняли, дальше непонятно. Исходный документ внутри. Evgeny_CD(07.04.2021 23:20, ссылка)
    - давно пора. Verilog сходу умеет 16'hDEAD_BEEF да 32'b0000_0101_1100_0011 - Mahagam(08.04.2021 00:42)
  - working draft — December 11, 2020 Evgeny_CD(07.04.2021 23:16, ссылка)
  - Общие принципы. - Evgeny_CD(07.04.2021 23:13, ссылка)
  - Список обсуждаемых документов - Evgeny_CD(07.04.2021 23:12, ссылка)
  - Загадочный документ Programming languages — a common C/C++ core specification. Вроде как драфт. Evgeny_CD(07.04.2021 23:10, ссылка)
    - Автор этого документа - Evgeny_CD(08.04.2021 00:31, ссылка, ссылка)
  - А им еще не пришла идея подавать идеи в стихотворной форме? - Cкpипaч(07.04.2021 23:08)
- Принципы, расписание - Evgeny_CD(10.01.2021 21:11, ссылка)
- Свежие новости про облик c22 - Evgeny_CD(10.01.2021 21:07, ссылка)
- computed goto опять нет, атомики только для hosted implementation. Древний косяк с функой clock() фиксить упорно не желают. Куды мир котится? - LightElf(13.03.2019 14:39 - 14:53)
  - Спасибо! Я раньше в смысл implementation не вникал, а тут вон оно что -> --> - Evgeny_CD(14.03.2019 00:38, ссылка, ссылка)
  - А какой косяк с функцией clock() ? Косяк был только у микрософта как всегда, у остальных так и написано: "процессорное время" (а не некое "физическое", или "календарное"). - fk0(14.03.2019 00:07)
    - Косяк в том, что стандартный clock() бесполезен в 99% случаев, by design. Счетчик очень быстро переполняется и функа тупо возвращает -1. Потому многие реализации нарушают спецификацию и возвращают значение по модулю. - LightElf(14.03.2019 11:40 - 11:56)
      - IMHO, косяк в том, что пытаются загнать в стандарт языка не операторы, но функции ввода-вывода. Эти потуги сродни "синдрому вахтера". - Vit(10.01.2021 22:19)
      - На счет 99% ты за уши притягиваешь. У кого-то CLOCKS_PER_SEC порядка 1000 и им 32-битного клока хватит на 50 дней. Померять время работы программы запущенной на 5 минут -- хватит. А кому не хватит, для них есть fk0(262 знак., 14.03.2019 13:29)
        
        Ну то есть это нормально, что стандартная функция по истечении времени просто перестает работать? Стандарт не ограничивает диапазон CLOCK_PER_SEC, хватает реализаций со значением 1000000, там переполнение за полчаса происходит. Стандартизаторов LightElf(132 знак., 14.03.2019 13:45)
        
        И в чём проблема? Все знают, что clock() можно использовать на коротких интервалах времени. А зачем она на длинных? Она для профилирования ПО, условно, а не для измерения времени. Её вообще для измерения времени использовать НЕЛЬЗЯ (потому, что fk0(213 знак., 14.03.2019 13:50)
        
        В том и дело, что не на "коротких интервалах", а на "коротком интервале от момента запуска программы". Т.е. профилировать можно только свежезапущенный процесс. Профилировать сложную, редко воспроизводимую проблему - нельзя. - LightElf(14.03.2019 13:57)
        
        Ты же сам говоришь -- берутся младшие биты по-модулю. Так что измерять можно в любой момент времени. Но измерения возможны только относительные, и только на коротком интервале. Наверное это не проблема. Кому вообще абсолютные нужны? И где fk0(318 знак., 14.03.2019 23:59)
        
        Младшие биты по модулю - это то, что всем и нужно от clock(). Стандарту такое поведение противоречит. По стандарту "считаем до 0x7FFFFFFF и шабаш, дальше возвращаем -1" и хрен весь. Со LightElf(125 знак., 15.03.2019 00:31 - 01:00)
- От языкового стандарта есть тот вред, что он описывает минимальный ("стандартный") набор функций, который любая реализация языка обязана иметь, однако разработчики компиляторов понимают это требование извращенно, удаляя из языка все Ксения(819 знак., 13.03.2019 13:11 - 13:15, ссылка, ссылка)
  - Невосполнимая утрата. Хотя... йцукен(194 знак., 13.03.2019 13:40)
    - Ваш код не совсем верный, т.к. младший coeffs[0] - свободный член, и на x он не множится. Но дело не в этом, а том, что на ассемблере такие вещи реализуются эффективней и работают они быстрее. Функция poly() полезна не сама по себе, а как Ксения(995 знак., 13.03.2019 14:03 - 14:09)
      - Это не мой код, и он вроде бы не умножает coeffs[0] на x. Я бы шаблон написал. йцукен(203 знак., 13.03.2019 14:24 - 14:37)
        
        Шаблон делу не поможет, т.к. после компиляции он выльется всё в тот же сишный код. Тогда как суть дела вот в чем: функции fmin(), fmax() и fma() появились потому, что в AVX/AVX2 появились новые процессорные инструкции, делающие эти операции "за Ксения(2147 знак., 13.03.2019 16:57 - 17:11)
        
        Разумеется, шаблон не для оптимизации, а для того, чтобы не писать отдельно для типов float, double и complex. Всего 4 строчки, но обычно в проекте не одна функция. - йцукен(14.03.2019 00:12)
        
        Интересно, за счет чего все же разница образуется? fma и обычный FPU в проце по-разному считают дабловую плавучку, у них не все разряды достоверные? - Evgeny_CD(14.03.2019 00:12)
        
        В разрядами у FPU87 всё отлично, т.к. он всегда считает в разрядной сетке float80, а при чтении и записи в память делает конверсию в float80 и обратно. Я до сих пор им пользуюсь, когда нужна повышенная точность. Исключение поддержки float80 Ксения(3348 знак., 14.03.2019 15:03)
        
        Я так понимаю, обычный FPU - наследник пресловутого 8087 с 80-битными регистрами, а всякие SSE и другие слова из трёх букв используют стандартный 64-битный double. - йцукен(14.03.2019 10:28)
      - long double - это четверная точность что ли? - Evgeny_CD(13.03.2019 14:09)
        
        Увы, в MSVC "long double" эквивалентен обычному "double", т.е. оба они float64, хотя язык формально их различает. Когда-то "long double" являлся float80, но потом его та же стандартизация попёрла прочь, сделав нелегетимным (хотя FPU всё еще его Ксения(100 знак., 13.03.2019 14:15)
        
        Клевета. Стандарт C99 не запрещает long double. - SciFi(13.03.2019 14:17)
        
        спасибо - Evgeny_CD(13.03.2019 14:16)
        
        Нет, это мрачное порождение 87 сопроцессора :( -> - Evgeny_CD(13.03.2019 14:15, ссылка)
        
        Сопроцессор FPU87 был удивительно хорош для своего времени! Даже тригонометрию и логарифмы умел считать, и точнее, чем нынешние. А сейчас доупрощались всмятку, заразившись дурью от RISC'а. :) - Ксения(13.03.2019 17:33)
        
        я вот всё хляжу на свои 80287 и прочие - может их приделать к Атымелю?) - Alex68(14.03.2019 00:45)
        
        Скотчем :) -> Хотя корпуса есть очень компактные :) - Evgeny_CD(14.03.2019 00:50, ссылка)
        
        вроде как интерфейс не шибко мудрёный. к атмеге какой думаю ног хватит подключиться) - Alex68(14.03.2019 00:51)
  - Расширенные функции - удел библиотек. Язык то тут причем? - Evgeny_CD(13.03.2019 13:20)
    - А при том, что язык - не только синтаксис. Вот и полезную функцию itoa() из языка попёрли, а где те библиотеки, которое восполняют функциональные потери? Кто их должен писать? Кто отвечает за их совместимость с компилируемым кодом и за пригодность Ксения(611 знак., 13.03.2019 13:44)
      - И правильно попёрли функции, которые не проверяют переполнение буфера. Вместо них ввели новые, которые проверяют. йцукен(275 знак., 13.03.2019 14:29)
        
        IMHO неправильно. "Си — инструмент, острый, как бритва: с его помощью можно создать и элегантную программу, и кровавое месиво" ©. Уж коли надо, чтобы проверяли, изучайте Pascal какой-нибудь. Лично меня такой подход, как и подход MISRA C/C++, shindax(201 знак., 13.03.2019 14:51 - 14:59)
        
        MISRA-то тут при чём? MISRA не даёт вам использовать свойства языка, и я согласен, это идиотизм. Я же говорил о функциях стандартной библиотеки, там "кровавое месиво" неуместно. - йцукен(13.03.2019 16:51)
      - Все эти улучшательства от мелкософта - борьба с конкурентами. Им за это по рукам шлёпнули. Хотите большого толстого злобного монополиста - хотеть не вредно. А нам такого добра не надо. - SciFi(13.03.2019 13:49)
- По сравнению со сверхскоростным развитием цэпэпэ, смотреть на развитие Си - грустно и умилительно - lloyd(13.03.2019 07:55)
  - Спецификацию C11 полностью осознать еще можно, C++17 - сомнительно. - Evgeny_CD(13.03.2019 09:53)
    - Ага, а потом смотришь на код людей, которые кроме Це ничего не знают, и рыдать хочется - lloyd(13.03.2019 10:30)
      - Обычно это все же код людей, которые С тоже не знают... - Evgeny_CD(13.03.2019 12:06)
      - На ваши плюсы и кути тоже без рвотных позывов смотреть сложно. Ничего, развиваем толерантность к альтернативно-одаренному. - Ralex(13.03.2019 10:33)
        
        Вот вот. Даже вполне качественный С++ embedded код -> смотрится как-то тяжеловато, не скользит по нему глаз с наслаждением. - Evgeny_CD(13.03.2019 14:12, ссылка)
        
        С++ может выглядеть как что угодно: от чистого Це до какого-нибудь C#/js - lloyd(13.03.2019 14:30)
        
        Верно. Но почему-то самым популярным является какой-то особый С++ вид, с кучей больших букв в идентификаторах, к которому надо привыкать отдельно :( - Evgeny_CD(13.03.2019 23:13)
        
        Это вопрос кодстайла. Очень удобна, например, ~~венская конвенция~~ венгерская нотация. LpZStrЁклмн ведь куда понятнее, чем просто "string"... fk0(5366 знак., 14.03.2019 00:47 - 01:04)
        
        А вот есть такой замечательный язык Nim(Nimron), так он вообще игнорирует регистр и подчёркивания, и гипотетическая иде может сама отформатировать не только по цвету и шрифту, но и по кейсу/снеку. Правда такой иде пока нет, но то такэ... :-) - =AlexD=(14.03.2019 14:41)
        
        В последнее время склоняюсь к такому описанию энумов т.к. редактор удобно подсказывает при вводе =AlexD=(90 знак., 14.03.2019 07:30)
        
        Большое спасибо! Очередной кусочек нетленки от fk0! - Evgeny_CD(14.03.2019 00:53)
        
        +100 - shindax(13.03.2019 14:56)
  - Как я понимаю, C11 полностью - так еще ни один компилер не могет. - Evgeny_CD(13.03.2019 09:51)
    - Вот что нарылось. Evgeny_CD(882 знак., 14.03.2019 00:41)
    - В С11 из бросающегося в глаза только анонимные структуры и объединения добавили да gets наконец убрали. У тех кто могет к 11 году всё это уже было реализовано. Интересное наблюдение, теперь не С++ оглядывается на С, а стандартизаторы С ЫЫукпу(39 знак., 13.03.2019 14:51)
  - Фундамент должен быть надежным! - Evgeny_CD(13.03.2019 08:08)
    - Покажи, где за этот фундамент платят денег? Программирование на нём отправляется куда-то туда, куда и программирование ассемблера. В узких местах имеет смысл, но в целом -- коммерчески невыгодно. Уже сейчас на каждом столбе нужен Go, C# и т.п. fk0(987 знак., 13.03.2019 13:05)
      - Странно, что на Go кодят в столь массовых количествах? - Evgeny_CD(13.03.2019 13:29)
        
        В последнее время очень силён "хайп-эффект". Когда о чём-то все говорят, они сами начинают в это верить, что оно самое самое. Особенно проявляется у молодежи не обладающей достаточной "исторической памятью", опытом что ли, чтоб не воспринимать fk0(1306 знак., 14.03.2019 01:18)
        
        Спасибо, согласен. Но! Чтобы столько народа пытались нанять, чтобы делать свои новые проекты на Go - это меня удивляет. А чтобы его использовали в каких-то популярных проектах, которые относительно массово используют в разных фирмах - я про Evgeny_CD(222 знак., 14.03.2019 01:28, ссылка)
        
        Ясно. На Go накодили кучу WEB фреймворков ->, вот видимо это и создает пользовательскую базу - Evgeny_CD(14.03.2019 01:30, ссылка)
        
        И пакетов под него наклепали немало -> - Evgeny_CD(14.03.2019 01:45, ссылка)
        
        Они не могут использовать ничего C/C++-ое, поэтому на каждый чих вынуждены писать своё. Такая же ситуация с C#, Perl, Python... качество тех пакетов обычно оставляет желать лучшего. - fk0(14.03.2019 01:52)
        
        Наверняка они придумали, как модули, написанные на С/С++, прикрутить к своему чуду :) - Evgeny_CD(14.03.2019 01:59)
      - Спасибо! Возразить особо нечего. Остается дождаться восхождения Rust - Evgeny_CD(13.03.2019 13:10)

Средства и методы разработки