Как стать автором
Обновить

Комментарии 28

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

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

С++2.0 в массы!

Интересно было бы посмотреть на язык программирования ++С.

Если я ещё/уже не забыл C/C++ (давно не использовал), префиксная запись означает, что, сначала, производится инкремент (то есть — приращение), а уже затем возвращается результат. В постфиксной, вроде бы, всё наоборот, сначала возвращается исходное значение, но, затем, происходит инкремент. То есть: результат операции (возвращаемое значение) является различным, но побочный эффект (в виде инкремента заданной переменной) остаётся одним и тем же. Я ничего не путаю?

Раньше имелось в виду, что C++ — это тот же язык C (синтаксис — результат), но с новым смыслом (семантика — побочный эффект). Вот я и думаю, что мог бы из себя представлять язык программирования ++С, у которого уже сразу изменён синтаксис, и этот новый синтаксис обеспечивает и новую семантику. В C++ изменение семантики происходило за счёт того, что каждую переменную можно было мыслить как экземпляр некоторого класса. Отсюда и расхожее представление, что C++ — это "C с классами".

Я мог бы предположить, только, что язык программирования ++С — это язык программирования, в котором сделан упор на перегрузку операторов. Должен действовать принцип: "всё есть оператор и всё может быть перегружено". Это значит, что и обыкновенные скобки должны стать полноценным оператором. Это придаст языку программирования С некоторые черты Python'а. Однако, такой подход означает, что и оператор for тоже может быть перегружен.

Ну это D получается.

Не уверен.

Верните нам наш Турбо Си 2.01 и МС Дос 6.0 !

(Нет, лучше закопайте их поглубже...)

[offtopic]

Turbo Pascal 5.0, 5.5 и 6.0. Turbo Professional и Object Professional. OWL. Watcom C. Foxpro. Lotus 1-2-3. Nowel Netware. PS DOS, DR DOS и OS/2 Warp. Лексикон и ChiWriter. Wolfenstein 3D. The But!

MODULA, SIMULA, OBERON, REFAL, ADA

CGA, EGA, VGA, Hercules

[/offtopic]

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

А как же обратная совместимость?

Обратная совместимость — это зло.

Но иногда -- наименьшее.

В C# есть элегантное решение: методы-расширения, когда первый аргумент становится, типа, объектом, а статическая функция — типа, методом. Вместо


ClassName.Reverse(ClassName.Take(ClassName.Reverse(x), 3));

можно писать


x.Reverse().Take(3).Reverse();

В C++ же такое невозможно, т.к. сломает ADL.

Поясните, пожалуйста, подробнее. Про ADL. Сам язык программирования, вроде бы, позволяет это сделать:

class Foo
{
  Foo& SomeMethod(){ return *this; };
}

Это и ломает ADL?

Я большой любитель ADL и не в курсе, как UFCS его ломает. Может быть есть примеры? Если взять идею из D, где не надо ничего указывать специально и любая функция может быть вызвана как метод на своём первом аргументе, то алгоритм простой:

1) Ищем метод на объекте, если есть зовём

2) Если нет, то ищем функцию по старым правилам, включая ADL.

Что не так?

Я большой любитель ADL и не в курсе, как UFCS его ломает.

Не помню, давно про это читал, в голове почему-то отложилось.

Что не так?

Всё логично. Но proposal-ы стабильно не проходят голосование, потому что вечно находятся причины против UFCS: каша с overload resolution или же необходимость всюду писать using namespace и т.д.

Но proposal-ы стабильно не проходят голосование, потому что вечно находятся причины против UFCS

Вот это, к сожалению, правда. Даже версия с вывернутым наизнанку UFCS не прошла, когда предлагали begin(vec) трактовать как vec.begin(), а не наоборот. В том же D на этом Ranges работают и не надо дополнительно перегружать |. Я не всегда понимаю комитет, порой они уж слишком осторожны.

и не надо дополнительно перегружать |

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

Больная проблема C++ — это пространства имён. Если вы хотим вызывать метод-расширение, то мы должны как-то сообщить компилятору, где его искать. В общем случае метод-расширение находится в отдельном пространстве имён, и для обычного вызова функции мы бы написали:

ns::ext::take(list, 3)

В случае расширения нам пришлось бы писать:

list.ns::ext::take(3)

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

А дальше мы вспоминаем, что в C++ есть ADL, и пытаемся заставить его работать: а именно, сделать так, чтобы один из аргументов функции был из нужного нам пространства имён. Хорошим кандидатом на эту роль оказались бинарные операторы:

list | ns::ext::take(3)

P.S. Собственно, вот что я имел виду, когда писал, что расширения ломают ADL — он попросту не работает с ними.

В случае расширения нам пришлось бы писать:

list.ns::ext::take(3)

Нет, не ужасно. Вполне нормально.

list | ns::ext::take(3)

Но так может даже и лучше.

В некоторых языках отдельный оператор заводят типа |>

В той библиотеке все методы LINQ определены в классе Shim<T> из файла linqcpp.h


Где расширения-то?

прошу прощения, не правильно понял комментарий.

Там используется костыль в виде From(...).

Ну и дичь вроде такой:

auto from = From( vector );
auto where = from.Select< std::unique_ptr< int >& >( []( std::unique_ptr< int >& m ) { return std::ref( m ); } );
…
auto v_select =
    From( { std::vector< TestType2 >( { TestType2( 1 ) } ), std::vector< TestType2 >( { TestType2( 1 ) } ) } )
         .SelectMany< TestType2 >( []( const std::vector< TestType2 >& s ) {
            return From( std::vector< TestType2 >( s ) ).Concat( std::vector< TestType2 >( { TestType2( 1 ) } ) );
         } )
         .Select< int >( []( const TestType2 t ) { return t._t; } )
         .ToVector();

Языку C++ очень не хватает компактного синтаксиса для определения лямбд.

Да c++ этим страдает

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

Вместо переработки языка в целом, появляются иные языки, что так же высоки по уровню и с возможностью быть "ближе к железу" - Rust к примеру

вот это поворот. А что говорят отцы например Шон Парент?

Сильно ли замедляется скорость компиляции по сравнению с обычными итераторами?
Публиковался перевод, где сравнивали Си и ranges, конечно шокирует немного, но в Си нет шаблонов, которые нужно инстанцировать на этапе компиляции, а вот как интересно STL vs STL 2.0 себя ведет

то ли у меня проблемы с восприятием, то ли перевод машинный и "кривой" по части терминологии

Зарегистрируйтесь на Хабре, чтобы оставить комментарий