Как стать автором
Обновить
87
0.2
Евгений Охотников @eao197

Велосипедостроитель, программист-камикадзе

Отправить сообщение
Да, было такое мнение. Вопрос потому и возник, чтобы узнать, а не поменялось ли оно со временем.

Ибо складывается ощущение, что C++-комьюнити само выбирает тот же CMake и ничего хорошего в этом нет :(

Плюс есть такой фактор, что когда люди говорят про модули, которые ожидаются в C++, то у многих складывается ощущение, что с пришествием модулей наступит такое же благоденствие, как в каких-нибудь языках с поддержкой модулей, вроде D или Rust-а, где сам компилятор может разобраться в каком порядке что компилировать. С большой долей вероятности в C++ это будет не так. Если только коммитет на озадачиться тем, чтобы у языка была своя де-юре стандартная система сборки.
STL — он же большой. Какие проблемы при отсутствии исключений вы ожидаете при использовании, скажем, std::find, std::count_if, std::transform, std::copy и др.?
Думаю, что время и опыт «молодых» языков, вроде Rust-а и Go, показывает, что «тулзы не имеют отношения...» несколько устарело.
У вас какие-то странные представления о кроссплатформенности. Ну и да, не весь мир пользуется CMake. И не желает, что характерно.
От оно чё, Михалыч… :) Ну будем посмотреть. Сам факт движения радует.
Вы их прямо в дерево проекта добавляете и дёргаете их сборку из вашего мейкфайла/CMakeLists.txt/.jam?
А как надо? Чтобы просто, кроссплатформенно, повторяемо?
А вот такой вопрос, не очень связанный с содержимым статьи, но связанный с развитием C++: а на заседаниях комитета всплывают вопросы отсутствия в C++ де-факто стандартных средств управления зависимостями и/или средств сборки C++ проектов?

Ну вот в том же Rust-е есть Cargo, которая снимает изрядную часть головной боли с растоманов. В C++ же все, такое ощущение, осталось неизменным с середины 80-х годов. Каждый волен извращаться как хочет. В итоге систем сборки как грязи, на любой вкус, что особенно доставляет, когда в одном проекте нужно объединить библиотеки, использующие разные системы.

Понятное дело, что стандарт C++ — он совершенно не про то, и в стандарте не будет прописываться какая-то система сборки. Но хотя бы эта проблема затрагивается в кулуарах?
Ну я смотрю на это так: если после прочтения статей у многих читателей остается непонимание того, зачем это нужно, где, когда и как это использовать, то это недоработка автора статьи. И тут либо ты находишь возможность разъяснить людям свой подход, либо миришься с тем, что твой подход не понимают и не используют.

Понятное дело, что на более подробное описание требуется много сил и времени. Но что ж поделать-то, продвигать «в народ» что-либо всегда сложно.
Ну вот здесь и рассказано: habrahabr.ru/post/267509
Как по мне, там не рассказано. Ты там просто говоришь, что можно сделать репликацию объектов и она в коде будет выглядеть вот так. Но что за репликация, какие к ней требования? Как приложение, в котором репликация требуется, должно реагировать на ошибки?

Т.е. хотелось бы видеть не абстрактную репликацию в вакууме, а более конкретное описание того, что нужно было сделать, как было сделано, почему было сделано именно так. Если будут показаны примеры других подходов, чтобы можно было наглядно сравнить, это было бы вообще здорово.
Тут надо смотреть на характеристику того или иного способа синхронизации.
Не, речь не про то. Вот когда человек видит что-то вроде foo.deferCall(bla-bla-bla), то он может предположить, что за этим скрывается какая-то непростая машинерия. А вот когда это выглядит как foo.call(bla-bla-bla), то догадаться о хитром поведении вызова не просто.
В целом, исходя из опыта могу сказать, что лучше написать меньше кода, чем больше.
Ок. Принято.
Субъектор появился в результате решения практической задачи про реплицированный объект.
Ну вот и надо бы рассказать про эту задачу, уверяю, далеко не все занимаются на C++ репликацией объектов по сети.
Статья большая и, хотя написана тщательно, воспринимается непросто. Возможно, она бы заходила лучше, если бы была разбита на несколько статей поменьше, в которые были бы включены примеры использования различных концепций. В текущем же своем виде она требует еще, как минимум, одной статьи, в которой будет разобран какой-то пример из реальной жизни (или с претензией на оную). Типа: вот традиционный подход и вот какой код вот с какими недостатками. А вот подход на субъекторах и вот как он устраняет эти недостатки.

Пока таких примеров нет, сложно судить о достоинствах предложенной модели. Да и прикидывать ее на задачи, с которыми сам имеешь дело, не так-то просто :(

Чисто с точки зрения здравого смысла возникает несколько вопросов:
— как программисту прикидывать, к каким накладным расходам приводит используемая им (или его коллегами) кухня? Например, написали некий класс Foo, обернули его в адаптер, потом накрутили вокруг него еще субъекторов. Как понять, насколько дорогим будет вызов Foo::bar?
— насколько просто будет работать с кодом, в котором Foo::bar может приостанавливать текущую короутину, запихивать функтор в канал, из которого кто-то что-то вычитает на другой рабочей нити, начнет обработку, телепортируется куда-то и т.д.? При том, что изменение одного слова в определении субъектора для Foo может кардинально поменять способ выполнения Foo::bar. Т.е. речь о том, что C++ и так ругают за то, что код на C++ отличается неочевидностью, здесь же неочевидность становится главной движущей силой.

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

PS. Отрадно, что разговоры в кулуарах конференции не прошли даром и появилось упоминание Симулы.
Но тогда Lock получается заточен только под std::mutex в качестве типа T_locker.
В разделе №4.2 в коде примера:
Lock _{lock_};
откуда берется имя Lock?
и т.д. printf по сравнению с ними просто сказка.
Ровно до тех пор, пока не придется использовать printf в обобщенном коде. Или до тех пор, пока не придется использовать printf для вывода в определенный пользователем поток данных.

Для тех, кто исходит на известную субстанцию от iostreams, уже давно есть fmtlib. Которая, среди прочего, позволяет работать с пользовательскими типами, для которых определены операторы сдвига именно в std::ostream.
std::optional не поможет вернуть код ошибки в случае неудачи. А вот аналог Rust-овского Result-а в стандартной библиотеке бы не помешал.
Ну, вообще-то, to_chars получает на вход char*. Что получил, то и вернул.

Другое дело, что к to_chars_result::ptr можно получить доступ даже если в to_chars_result::ec находится код ошибки… Вот это не есть хорошо. Какой-нибудь std::variant<char*, std::errc> был бы, наверное, уместнее. Но, вероятно, с точки зрения эффективности to_chars_result обходится дешевле.
Вот от этого фрагмента прям какой-то теплой ламповой сишечкой повеяло:
auto res1 = std::to_chars(arr, arr + 128, 3.14f);
Может имело бы смысл его записать в духе современного C++?
auto res1 = std::to_chars(std::begin(arr), std::end(arr), 3.14f);
Как-то понадежнее будет.
Проблема даже не в том, что я не ученый. А в том, что вы не пятилетний ребенок. И объяснять вам простые вещи у меня уже нет ни желания, ни терпения. Равно как и учить вас считать строки.
В чём оно ошибочное?
В основе своей.
Сложность синтаксиса языка не отрицает того, что сложная для понимания программа или простая — это результат работы программиста.
Посмотрим на исходный тезис:
Простота кода зависит не от языка, а от программиста.

И смотрим на пример программы на J:
quicksort=: (($:@(<#[), (=#[), $:@(>#[)) ({~ ?@#)) ^: (1<#)

Вряд ли в этой программе есть что-то сложное, обычный такой quick sort. Сложным для восприятие ее сделал не программист, а синтаксис языка программирования.
Фразы «глаз замылиться» и «парадокс Блаб-программиста» не делают понятнее то, что вы хотите сказать…
Ну извините, разжевывать еще подробнее нет желания.

По поводу количества строк. Скобки нет смысла считать. Так что там всего три строки. Но если вы хотите подсчитать скобки, то будет либо 4, либо 5, в зависимости от расположения открывающей. Но подобный подсчет выглядит еще более тупым занятием, чем попытки сравнить простоту и выразительность C-шного и C++ного кода.
Вы используете brainfuck в работе?
Для демонстрации ошибочности вашего утверждения этого не требуется. Ну если хотите примеров того, что люди используют в работе, то посмотрите на какой-нибудь Q или J.
Можете пояснить, что конкретно вы имеете в виду?
Если вы вынуждены плотно заниматься сетевым программированием на чистом C и привыкли это делать так, как разработчики nginx, то у вас может просто «глаз замылиться». Ну и парадокс Блаб-программиста так же может иметь место быть.
У васт большой опыт написания программ на C, да?
Возможно, опыт написания программ у меня просто больше, чем у вас. Если вы говорили про 1997-ой год, то точно больше. Ну и C был одним из тех языков, с которых приходилось начинать. И ушел я с него при первой же возможности, т.к. даже в начале 90-х было понятно, что использовать C по собственной воле могут не только лишь все.
В моём коде вы предложили сократитить 2 повтора по 2 строки лямбдой в 5 строк и плюс по одной стоке на каждый повтор вместо двух.
Вообще-то три повтора. В двух из которых еще и нужно было функцию очистки явным образом вызывать. И если вы в лямбде насчитали пять строк, то у вас еще и проблемы со зрением.
Ваш код стал менее читаемым, длинее и дольше в написании…
Ну тогда понятно. Вопросов больше не имею.

Информация

В рейтинге
2 057-й
Откуда
Гомель, Гомельская обл., Беларусь
Зарегистрирован
Активность