Герб Саттер — отчёт о встрече по стандартам ISO C++ в июне 2025 года

Не знаю как выразить линейные типы, но я и С++ не знаю. Все же как не возьму его на пробу, чего то вечно не хватает. Но если говорить о средствах которые гарантируют безопасность, вместо линейных типов которые перекладывают работу на программиста, готовятся к C++26 контракты, это шаг в сторону Ada Spark: https://en.cppreference.com/w/cpp/language/contracts.html

отовятся к C++26 контракты, это шаг в сторону Ada Spark: https://en.cppreference.com/w/cpp/language/contracts.html

Скорее это заимствование из Eiffel (где Design by Contract впервые появились) и D.

Опять этот бред про «перекладывание работы» какой работы? куда? А другие типы за программиста сами пишут, или что? Spark-и так-то многократно большее перекладывание, как и громоздкая, уродливая, но довольно бестолковая возня с типами в плюсах. А ещё бОльшая работа, это долбаная бесконечная отладка проблем и с памятью, и с многопоточкой, и обходом ограничений рантаймового GC, и логикой( да, линейные типы - это не только и не столько про память). Если покусал царь пропей курс каких-нибудь CS антибиотиков

Чего так порвался? Давай подробно объясню свое мнение: Линейные типы заставляют менять логику и подход к программированию, так же как это заставляет делать функциональное программирование. И линейные типы, и функциональное программирование облегчают работу компиляторам, и программист может вытянуть из этого преимущества, но минусы никуда не уходят.

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

Ты сразу начал говорить какой Spark сложный, но он предоставляет инструменты которых в убогом Rust никогда не будет, даже сейчас -fanalyzer способен искать ошибки в С, которые компилятор Rust скорее всего никогда не научится находить из за своего убожества. Полное обмазывание Spark это думаю сложно, но введение контрактов и концептов в С++ не обязывает использовать их в каждой строке.

Там они скорее всего только в RT проверяются. В Ada Spark они могут проверяться в момент компиляции, и я надеюсь что будет следующим шагом для контрактов из С++.

Там они скорее всего только в RT проверяются.

В Eiffel, D и С++?

Да, проверяются в run-time. Хотя, т.к. в D и в C++ есть constexpr, то для constexpr-функций, по идее, должны бы проверяться в compile-time, если в compile-time эти функции вызываются.

Вроде бы ходили разговоры, то наличие контрактов может позволить оптимизаторам делать те или иные оптимизации в коде.

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

Почему точно не будут? Уже сейчас есть -fanalyzer, я надеюсь на его основе что то будет сделано. Сейчас им тоже можно строить контракты, вот например контракт на проверку что бы x не был 15.

#include <stdio.h>
#include <limits.h>

void foo(int x)
{
  // contract(x != 15);
  {
    if (x == 15)
      x = -1;
    int arr[INT_MAX];
    arr[x] = x;
  }  

  // begin code
  printf("foo\n");
}

int main(int argc, char **argv)
{
  if (argc != 15)
    return 0;
  foo(argc);
  return 0;
}

И работает, а делает его всего один разработчик временами.

А так уже предупреждений нету:

-  if (argc != 15)
+  if (argc == 15)

Афинные и линейные типы туда еще не завезли вроде бы? Пора бы и это следом за рефлексией, чтобы растофанов корёжило.

Судя по этому и предыдущим топикам, от новых фич в крестах корёжит в основном крестовиков.

от новых фич в крестах корёжит в основном крестовиков.

Нам же с этим потом жить, а когда новые фичи сделаны, например, с черезжопным синтаксисом (как та же рефлексия), то абыдна как бы.

Про GC конечно смешно написал, я сначала подумал ты про Rust, где RC-GC рантаймовый, самый худший из GC.

Причем в Rust сам программист еще подрабатывает за GC, без получение преимуществ из С где программист может использовать недоказуемое, но рабочее и быстрое решение по управлению памятью.

А есть подход с автоматизацией, как в ML Kit, когда компилятор не просто помещает все в GC, если он видит что переменная не используется за пределами функции то он выделит ее в стеке. А если они перемещаются, он выводит область в которой переменная может находится, и сам строит арены для объектов на разных уровнях кода, которые обеспечивают быструю аллокацию и очищение. В такой модели GC существует лишь там, где совсем невозможно статически определить время жизни переменной, но в таких случаях обычно руками уже ничего не сделаешь и в C/Rust, там начинают применять счетчики, а в языке более высокого уровня, может быть решение лучше.

И все это без мучения программиста как в Rust. Вот еще если кажется что я говорю только про какие то академические, несуществующие вещи: 1) https://blog.janestreet.com/oxidizing-ocaml-ownership/ 2) https://blog.janestreet.com/oxidizing-ocaml-parallelism/

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

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

Заключение: Фанаты Rust это луддиты которые застряли в модели Fortran 66, и боятся одной только мысли, что возможна какая то автоматизация в инструментах программирования.

Линейные типы заставляют менять логику и подход к программированию

Ровно в той же степени, что и использование любой другой фичи.

Есть разница между ФП в Haskell и С++, во втором можно применить по месту, но если хочется можно и std::cout вставить в середину функции (IO), в Haskell же не получится выйти из тюрьмы в которую программиста посадил язык, есть unsafe, но что если больше половины проекта не следует начальной идеологии? Будет забивание микроскопом гвоздей.

Почему точно не будут? Уже сейчас есть -fanalyzer, я надеюсь на его основе что то будет сделано. Сейчас им тоже можно строить контракты, вот например контракт на проверку что бы x не был 15.

Да, крутая штука.

Ну там синтаксис всратый, а так фичи-то хорошие.

Современное состояние C++ напоминает мне языки 60-70-х, когда на уровне синтаксиса наворачивали «всего и побольше», получая монстров даже по современным меркам. А потом те же идеи научились выражать, не наворачивая по десятку ключевых слов в кучу.

Вот в крестах исторически получается такое же нагромождение.

Потом на его смену придут более удобные языки. Но пока как полигон для отладки идей, годятся и кресты.

Синтаксис и правда всратый, не верится, что нельзя было сделать лучше.

В D есть GC, который фактически не отключается (флаг -nogc у ldc не работает). GC в таком языке нафиг не нужен, когда есть RAII и возможность написать умные указатели.

В такой модели GC существует лишь там, где совсем невозможно статически определить время жизни переменной, но в таких случаях обычно руками уже ничего не сделаешь и в C/Rust, там начинают применять счетчики, а в языке более высокого уровня, может быть решение лучше.

Это очень оптимистичный взгляд на то, как оно работает. Но для функциональщины немного линейности это очень полезно, это да.

Ты сразу начал говорить какой Spark сложный, но он предоставляет инструменты которых в убогом Rust никогда не будет

Creusot и Verifast уже существуют. Ты бы посмотрел, над чем там люди работают в «убогом» расте для начала. Вот, держи папир: https://arxiv.org/abs/2403.15122.

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

А еще есть целый QT, который на C++26 сможет работать без MOC.

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

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

и да, ещё пока никто не может сказать, не повлияет ли это на производительность. если да, то тогда это никуда пихать не нужно.

его сначала надо переписать

Ничего там не надо переписывать, нужно будет только поменять рефлексию с moc на нативную из цпп26, что совсем небольшая часть проекта.

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

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

Прежде всего это заставляет делать задача, и для системщины линейные типы подходят больше всего

И линейные типы, и функциональное программирование облегчают работу компиляторам,

Именно программистам они впервую очередь и облегчают, их для этого и придумывают, как и вообще любые высокоуровневые языки.

Ты сразу начал говорить какой Spark сложный, но он предоставляет инструменты которых в убогом Rust никогда не будет,

ути пути, тебе там сам боженька на ухо шепчет что где будет, а где нет? про Creusot и Verifast уже упомянули. На каждые утилитки и сайтеги будем разорятся со спарками? Раст потому и взлетел что представляет разумный и практичный компромисс между слишком дорогими спарками-агдами и болотом из идейных потомков сишечки хоть с GC хоть без

даже сейчас -fanalyzer способен искать ошибки в С, которые компилятор Rust скорее всего никогда не научится

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

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

Типы, именно современные из CS, на полшишечки будут почти что бесполезны

очередной малограмотный прогон про GC

Вот смотри, в хаскеле и идрисе есть ОДНОВРЕМЕННО и GC и линейные типы, которые ещё строже растовских аффинных,если чё. Как думаешь, зочем?

не заставляют программиста изворачиваться, мучения программиста как в Rust

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

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

Вот смотри, в хаскеле и идрисе есть ОДНОВРЕМЕННО и GC и линейные типы, которые ещё строже растовских аффинных,если чё

Так и деструктор с GC вещь полезная. Я ничего против возможностей не имею. Ты лучше подумай почему ты пишешь в 2025 году на языке без GC свои «сайтики». Почему любой Wordpress-программист пишет на языке более инновационном?

Типичный программист на Rust, пришел из мира JS, и склонен подключать под сотню пакетов, ты думаешь такой человек сможет быть умнее чем условный Java GC?

Недостаточно иметь контроль, это как с ассемблером, надо держать Rust-фаната от него подальше, он только может сделать еще хуже, потому что он глупее оптимизатора, глупее GC, управление памятью это для людей которые что то в этом понимают, оставь это C/C++ программистам.

Тупо на ходу выдумываешь какие-то «проблемы»

К счастью проблемы которые привносит ручное управление памятью давно известны, так что мне не надо ничего придумывать... Ты же даже не можешь список нормальный на Rust построить, что уж говорить о объектах со сложной логикой.

Вот я уже помню две больших статьи про то как люди отказываются от Rust для разработки игр, в обоих случаях приводят пример что сложно строить связанные структуры. Проблема известна всем, и даже растофанатам вроде тебя, но вы ее просто отрицаете. Наверное потому что на своем поделии ничего сложного не пишите?

Нет, никакие анализаторы исходную сишку уже не исправят, задним числом и в общем случае это просто невозможно.

Какой еще общий случай, мы вроде про конкретный язык говорим. Rust кстати видимо тоже не получится уже исправить, хотя может он по твоему не общий случай. Так вот, -fanalyzer это очень удобно, и требует ноль действий со стороны программиста, я же весь комментарий построил на сравнении автоматизации и ручного метода. Я не говорил что он сравним со SPARK по своей мощности, зачем ты приписываешь мне какие то слова?

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

Зря я полез дураку что то объяснять, признаю. Впредь ошибки не повторится! Вместо очередного ответа в стиле /b/, советую внимательно прочитать мои комментарии, и ссылки которые я оставил.

Я описываю подход автоматизации против ручного управления памятью, конкретно такого GC я не знаю, а ниже ссылка которая описывает уже существующее положение в OCaml JaneStreet.

И для C есть внешние инструменты, только французская лаба далека от SPARK.

Да, проект которому больше десятка лет, более зрелый, чем проект, появившийся года три назад. Но зрелость к делу не относится, так как ты сказал, что ничего подобного в расте никогда не будет.

Я не считаю что это сравнимо со SPARK. Не вижу противоречий, может понять меня поможет другой пример, я так же считаю что на Rust никогда не создадут чего то сравнимого с Qt, хотя несомненно для него есть кривые библиотеки для GUI.

То что проект молодой, не означает что он станет качественным через N лет. Вот как пример Wayland, не сказал бы что ему лучше становится.