LINUX.ORG.RU

C++, который мы потеряли

 


1

5

https://habrahabr.ru/company/infopulse/blog/279927/
https://www.facebook.com/olegchir/posts/1093480147341658

tldr: модули, концепты, транзакционная память, унифицированный синтаксис вызова, дедуктивный вывод параметров шаблонов, сопрограммы, контракты, рефлекшен, constexpr if, расширения для работы с сетью - ничего этого НЕ будет в 17

★★★★☆

Последнее исправление: stevejobs (всего исправлений: 1)

StrangerInRed с хабра, случаем не местный царь сишки? Уж больно уровень неадекватности у обоих зашкаливает.

RazrFalcon ★★★★★
()
Ответ на: комментарий от registrant27492

А зачем тебе синхронизация в либм?

Захотелось мне sqrt внутри транзакции использовать.

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

Откуда?

Т.е. два вызова синуса от одинакового значения - он заменит на один, так же как и два strlen"а.

Компиляторы C++ умеют в полноценную мемоизацию? Серьёзно?

Ну там пацаны не про софтвар писали.

Это детали реализации, что не так важно.

Да и прифнт же буферизованный - не факт, что там будет сискол.

Не факт что его не будет.

Ну пдфка то ещё дерьмо, конечно.

То же можно написать про многие другие части C++.

А так - я отвечал про то, что в целом этому(наличию stm/htm) ничего не мешает.

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Захотелось мне sqrt внутри транзакции использовать.

Это не имеет смысла. Конпелятор вынесет её за рамки транзакции.

Откуда?

Оттуда. Из таблички - все нормальные конпеляторы завязаны на свою/конкретную libc.

Компиляторы C++ умеют в полноценную мемоизацию? Серьёзно?

Что значит полноценную? https://godbolt.org/g/h31iev Достаточно умеет.

Это детали реализации, что не так важно.

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

Не факт что его не будет.

Это ничего не меняет. Факта нет - это всё, что я хотел сказать.

То же можно написать про многие другие части C++.

Это дерьмовей.

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

Какие баги. Тебе объяснили - никакие эффекты отслеживать не надо.

Хотя ладно - это бесполезно, если ты просто игноришь.

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

registrant27492
()
Ответ на: комментарий от registrant27492

Это не имеет смысла. Конпелятор вынесет её за рамки транзакции.

synchronized {
    x = sqrt(x);
    y = y + 1;
}

Что здесь будет вынесено за рамки чего?

Оттуда. Из таблички - все нормальные конпеляторы завязаны на свою/конкретную libc.

clang и gcc умеют использовать любую libc, которую ты им подсунешь. И что делать с функциями не из libc?

Какие баги. Тебе объяснили - никакие эффекты отслеживать не надо.

Кто объяснил? Ты ничего не объяснил.

Багов никаких не будет. Их быть не может.

Ты это каждый день перед зеркалом себе говоришь?

сейчас то же самое с тредсейфом - никому это не мешает.

Туева хуча багов, вызванных гонками в коде, или дедлоки никому не мешают. Ок.

hateyoufeel ★★★★★
()
Ответ на: комментарий от registrant27492

Багов никаких не будет. Их быть не может. Как я уже сказал - сейчас то же самое с тредсейфом - никому это не мешает.

Треды-то тут причем? Там memory barrier + wait_queue - там вообще насрать, чистые у тебя вычисления или нет.

kirk_johnson ★☆
()
Ответ на: комментарий от hateyoufeel

Что здесь будет вынесено за рамки чего?

Здесь будет 2 хардварных коммита.

clang и gcc умеют использовать любую libc, которую ты им подсунешь.

И? Кого это волнует и что из этого следует?

И что делать с функциями не из libc?

Тебе уже объясняли - если доступно тело - конпелятор выявляет её итак - если что-то не выявляет - это поправят. Если тело не доступно - твои проблемы. Я выше писал, что ipo(lto) решает эту проблему - в 2020-м вместе с stm оно придёт везде.

Кто объяснил? Ты ничего не объяснил.

Объяснил. Ты заигнорил. В целом уже 3-4 лужи и 3-4 игнора достаточно для выявления твоей осведомлённости и понимания в теме.

Туева хуча багов, вызванных гонками в коде, или дедлоки никому не мешают. Ок.

Опять эти детсадовские сливы - ну не юзай - багов не будет.

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

registrant27492
()
Ответ на: комментарий от registrant27492

Здесь будет 2 хардварных коммита.

Ты точно понимаешь что такое транзакции и как они должны работать?

И? Кого это волнует и что из этого следует?

Меня. И ещё кучу других разработчиков.

если доступно тело - конпелятор выявляет её итак

Каким образом? Я забуду на секунду о том, что в 99% случаев в C++ тело функции недоступно.

ipo(lto) решает эту проблему

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

никому это не помешало реализовать поддержку тредов.

Ты точно умеешь читать?

hateyoufeel ★★★★★
()
Ответ на: комментарий от kirk_johnson

Треды-то тут причем? Там memory barrier + wait_queue - там вообще насрать, чистые у тебя вычисления или нет.

Причём тут чистые или нет? Почему вы такие сложные.

Пацан просит гарантию synchronized-safe для функций, типа без этого synchronized нельзя, когда как никакой гарантии thread-safe так же нет и thread можно. Откуда ты взял, что «там вообще не насрать, чистые у тебя вычисления или нет.»?

registrant27492
()
Ответ на: комментарий от registrant27492

Пацан просит гарантию synchronized-safe для функций, типа без этого synchronized нельзя, когда как никакой гарантии thread-safe так же нет и thread можно.

ТОЛЬКО НЕ МОЙ МОЗГ *БАНЫЕ ПРИШЕЛЬЦЫ! Серьезно, я не понимаю, что ты пытаешься сказать.

Откуда ты взял, что «там вообще не насрать, чистые у тебя вычисления или нет.»?

Потому что так и есть. У тебя есть локальная к треду память, у тебя есть общая память, и у тебя есть блокировки, чтобы получить сериализованный доступ к общей памяти.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

Серьезно, я не понимаю, что ты пытаешься сказать.

Слишком сложно.

Вон там выше было ++i; с принтфом. Где пацан говорит, что притф не synchronized-safe и типа беда.

Берём ++i хреначим на него volatile и мембарьер, либо в атомик засунул и пишем это не thread-safe принтфом(допустим от коллеги федота). Тебе поможет барьер и прочие куллстори? Нет.

А теперь внимание вопрос - почему на гарантию thread-safe все забили и треды есть. Т.е. конпелятор так же не может выявить thread-safe, как и synchronized-safe. В языке так же нет таких понятий и флагов на уровне функций и прочего.

Почему в одном случае это не мешало, а в другом помешало?

Потому что так и есть.

Перечитай. Там было про неправильную тобою интерпритацию моих слов, а не то, что для thread-safe надо выявлять чистоту или что ты там подумал.

registrant27492
()
Ответ на: комментарий от registrant27492

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от RazrFalcon

В C++ я могу располагать сорцы как угодно

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

Когда последний раз смотрел - была костыльной. По умолчанию - статика.

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

(если я правильно понял, то бинарник у либы ровно один).

Да, один. Но опять же, очень многое просто в другие библиотеки вынесено. Не уверен, что есть смысл эту дробить. Тем более, что есть libcore.

DarkEld3r ★★★★★
()
Ответ на: комментарий от registrant27492

Слишком сложно.

Вон там выше было ++i; с принтфом. Где пацан говорит, что притф не synchronized-safe и типа беда.

Берём ++i хреначим на него volatile и мембарьер, либо в атомик засунул и пишем это не thread-safe принтфом(допустим от
коллеги федота). Тебе поможет барьер и прочие куллстори? Нет.

А теперь внимание вопрос - почему на гарантию thread-safe все
забили и треды есть. Т.е. конпелятор так же не может выявить thread-safe, как и synchronized-safe. В языке так же нет
таких понятий и флагов на уровне функций и прочего.

Почему в одном случае это не мешало, а в другом помешало?

Молодец, кажется ты начал понимать разницу. Thread-safety обеспечивается программистом. А STM перекладывает это на цомпилер. Тебе всего лишь нужно обозначить границы транзакции.

kirk_johnson ★☆
()
Ответ на: комментарий от DarkEld3r

Ну да, и что?

Ок, в лоб: можно тесты хранить отдельным проектом? Вообще в другой папке? К примеру тесты весят много, не хочется их тягать в основном дереве.

RazrFalcon ★★★★★
()

2 all: если хотите заняться просвещением царя о STM и прочем, создайте отдельную тему.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Имелось ввиду вообще отдельно. Не в директории основного проекта.

RazrFalcon ★★★★★
()
Ответ на: комментарий от nikolnik

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

реализуемо практически. см. диссер К. Книжника про ООСУБД Goods, ~1997 год, C++98.

anonymous
()
Ответ на: комментарий от anonymous

хотя полноценной интроспецией (интроспекцией + интерцессией, как в более других языках) это можно назвать только лишь с большой натяжкой. однако ж.

anonymous
()
Ответ на: комментарий от grem

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

читай 102740024-05-01-acc.pdf , интервью со Страустрапом про design decisions С++. он фапал на быстрые массивы как в фортране. ряд костылей и ограничений С++ там довольно чётко обозначен.

anonymous
()
Ответ на: комментарий от RazrFalcon

Ок, в лоб: можно тесты хранить отдельным проектом? Вообще в другой папке?

А как эти тесты будут находить бинари из проекта? Они же от либ завидеть должны, наверное? А вообще никто не мешает создать отдельно проект, прописать там зависимости от тестируемых либ и держать там только сами тесты.

Или даже ещё более в лоб, причём решение будет не зависеть от Cargo вообще: кладём тесты отдельно, делаем для удобства таргет для их скачивания в корень проекта и добавляем их в игнор. Кому надо - качает/запускает.

Но опять же, это скорее «ограничение» Cargo, а не модулей и их привязки к файловой системе.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Зачем сразу бинари? Иногда достаточно пары файлов (я знаю, что в расте принято писать unit тесты прямо в коде, но меня этот вариант не очень устраивает, так как тесты будут в 10 раз больше кода).

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Читал уже. По ссылке ничего о том, что мне нужно - нет.

Как маленький ребёнок. Туда отведи, то покажи.

$ tree .
.
├── foo
│   ├── Cargo.toml
│   └── src
│       └── lib.rs
└── foo-tests
    ├── Cargo.toml
    └── tests
        └── lib.rs

4 directories, 4 files

$ cat foo/Cargo.toml 
[package]
name = "foo"
version = "0.1.0"

$ cat foo/src/lib.rs 
pub fn hello_world() -> &'static str {
    "Hello, world..."
}

$ cat foo-tests/Cargo.toml 
[package]
name = "foo-tests"
version = "0.1.0"

[dependencies]
foo = { path = "../foo" }

$ cat foo-tests/tests/lib.rs 
extern crate foo;

#[test]
fn test_foo_hello_world() {
    assert_eq!(foo::hello_world(), "Hello, world...");
}

$ cd foo-tests

$ cargo test
   Compiling foo v0.1.0 (file:///home/user/tests/foo)
   Compiling foo-tests v0.1.0 (file:///home/user/tests/foo-tests)
     Running target/debug/lib-0a3c865d08d6b73a

running 1 test
test test_foo_hello_world ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured


anonymous
()
Ответ на: комментарий от RazrFalcon

Иногда достаточно пары файлов

Ну да, так раст не умеет. Впрочем, в С++, в общем случае, так тоже не очень правильно делать - эти несколько файлов могут завидеть от опций сборки и т.д.

Но опять же, вариант с отдельной репой, которая скачивается в корень основной, вроде, подходит.

так как тесты будут в 10 раз больше кода

И что?

DarkEld3r ★★★★★
()
Ответ на: комментарий от RazrFalcon

я не совсем понял, что ты хочешь, но может быть, тебе помогут git submodules? Один каталог исходников, а репозитория - два, две истории

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от RazrFalcon

Привык к: отдельно код, отдельно тесты.

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

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

DarkEld3r ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.