LINUX.ORG.RU

про то, как видеть C++

 , ,


2

3

Ещё не выздоровел до конца после темы с воспалением легких и легко устаю, и вот посреди одного доклада по C++ на конференции я натурально уснул, и во сне приснилось удивительное.

Проснувшись я стал смотреть на синтаксис C++ и видеть его сквозь призму того, что читал о Haskell (никогда не программировал на нём, а только писал хэлловорлды), и своего небольшого опыта со Scala - всякие scalaz, cats, итп.

Если в глазах иметь своеобразный фотошоп, который выбрасывает из синтаксиса C++ __Уродливые_Идентификаторы и [квадратно](гнездовые) -> конструкции, то на поверхность проступает красота и логичность происходящего. Ты видишь аппликативные функторы и произростающие из них монады, которые просто томятся в застенках из покосившехся скобочкек и отсутствия базовых вещей вроде каррирования.

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

Есть подозрение, что разработчики стандарта это понимают, принимают C++ как язык общего назначения (а не только для написания низкоуровневых системых вещей), и улучшают синтаксис и стандартную библиотеку с целью минимизации в необходимости этого выверта восприятия. Вполне возможно, через десяток лет на C++ будет так же просто писать, как на Haskell или Python. А сейчас придётся ну, самостоятельно заниматься расширением сознания

Подскажите, верно ли моё восприятие? Как двигаться в этом направлении? Нужно ли мне углубляться в Haskell параллельно с изучением C++?

★★★★☆

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

Вполне возможно, через десяток лет на C++ будет так же просто писать, как на Haskell или Python.

Комитет не позволит, так же вся илитарность потеряется.

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

Тебе сказали идею - применяй голову, в идее есть здравые исключения. Ты похвастался как разбил голову об кирпич (применение головы, без включения мозгов). Объясняйся

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

То ли дело Си. Там ничего особо нового нет.

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

А чье мнение и на основании чего считать объективным и почему?

Ничье. Мнения субъективны. Поэтому незачем прибегать к приемам вроде «а вот чувак с 20-ью годами опыта сказал», потому что всегда найдется другой чувак, который говорит обратное.

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

У них есть выбор.

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

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

Что это за поток неведомой ахинеи? Я помножил на ноль трепло, а ты не осилив что-то ответить - начал генерировать рандомный бред? Сильно. Объясняйся, как твои потуги связаны с тем, что говорил я и на каком основании я вообще должен на эту херню отвечать?

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

Ага...

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

Вы хотите чтобы Вам выдали язык, где есть Одно, Единственно Правильное для Всех Случаев Решение? Так не получится. Ни в С, ни в С++. Вам там выдали простые типы данных, а дальше уже либо сами ваяйте абстрактные типы (списки, очереди и прочее) что Вам нужно в данном конкретном случае, либо берите STL для С++, либо GLib для С и используйте что там предложено. Выбор за Вами. И ответственность за косяки на Вас.

Но вот для C++ он не работает и это плохо.

И в С и в С++ предполагается что человек прилагает усилия к тому, чтобы понять и осмыслить. Это языки с крайне высоким порогом вхождения, есть такое. Либо Вы погружаетесь туда целиком, либо по верхам. Некоторые вещи здесь могут быть «по историческим соображениям» или «так принято», некоторые вещи могут иметь техническое обоснование. Но вот я не знаю JavaScript, например, дальше jQuery (и то использую так, от случая к случаю) и не чувствую себя обойдённым.

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

Ещё раз. Тебе сказали принцип. Ты его похакал, потому что ты у мамы самый умный. Но никто не утверждал что надо как робот бегать и копировать без разбору код стандартной библиотеки. О боже, в низкоуровневом коде с Pin есть unsafe. Срочно unsafe в мой факториал

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

Тогда это был бы не С. =)

Было бы, если бы без #include «file.h» идентификатор __stupid_global был видим.

Считайте это «защитой от дурака», точнее, её попыткой на уровне исходного кода. Если бы её не было, то это был бы на фиг какой-то JavaScript (и тут в меня ща ссаные тапки полетят...). =)))

Однако вопрос был «бывают ли»? Бывают. И это мы поговорили пока только про исходный код. Потому как дальше я просто обязан вспомнить про такую вещь, как оптимизация gcc под названием global register allocation. Т.е., gcc, при оптимизации, пытается сохранить переменную в случае её частого использования в регистре процессора. Тем самым, минимизировав пересылки регистр-память. И вовсе не факт, что переменная, которую Вы определили и проинициализировали где-то в одном из файлов, внезапненько так не будет храниться в регистре процессора в течении всей жизни Вашего приложения (ну например демона с аптаймом в несколько лет). Просто потому, что gcc решил что к данной переменной в течении работы процесса будет много обращений и нефиг её гонять из памяти в регистр и обратно, а выгоднее хранить в регистре. Так что, зарекаться я бы тут вообще-то не стал. Вы написали код? Хорошо. Но что по данному поводу думает компиль, как правило, мало кто задаёт этот вопрос.

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

potential scope

Хорошая формулировка. Не находите?

A name with global namespace scope is said to be a global name.

Да. Всё так. Вы задефайнили глобальное имя? Вы. Оно с префиксом в подчёркивании? Да. Потенциально кто сделал херню? Программист (Вы или я, не столь суть). Ну вот и радуйтесь. Ответственность-то за это на Вас, а не на ком-то. Я не зря такое имя дал переменной, повторяю ещё раз. =)

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

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

Но никто не утверждал что надо как робот бегать и копировать без разбору код стандартной библиотеки.

А где я это утверждал, балабол? Где я вообще об этом говорил? Пациент писал - «std - пример для подражания». Тебе показали пример - подражай. Но т.к. ты сел в лужу и не осилил ничего ответить - ты начал маневрировать.

Поэтому, ты либо отрицаешь тезис «std - пример для подражания», либо ты помножен на ноль. В любом случае ты помножен.

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

Твой папка пример для подражания? Если да, будь последователен, трахни свою мамку

vertexua ★★★★★
()

Капец ты альтернативщик. Плюсы, значит, стрёмные, а хаскель, целиком состоящий из закорючек, норм. Ну ок.

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

Какие, пилять, новые исходники. Стандартные заголовочные файлы, в которые вы заглядываете, имеют историю в несколько десятков лет развития. По крайней мере первые реализации STL — это район 1992-1993 годов, с 1994-го их начали затаскивать в stdlib.

А кто говорит о первых реализациях STL? Или в них с тех пор никто не лазил? Стандартная библиотека это часть компилятора, её можно и нужно обновлять вместе с ним.

Еще один «малолетний дебил» (с) выступает за все хорошее против всего плохого. Не знаю, не понимаю, но мнение имею.

Ну если «престарелых дебилов» не тыкать носом в дерьмо, они и не поймут, где воняет.

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

Хорошо, из этого(https://github.com/rust-lang/rust/blob/master/src/libcore/option.rs#L268) следует, что писать положено с unsafe? А методичка говорит обратное - объясняйся.

Где ты такую методичку выкопал? Если нужен unsafe, значит его надо использовать. Если ты считаешь, что этот кусок можно переписать без unsafe, где твой пул-реквест?

Legioner ★★★★★
()
Ответ на: Не, ну так-то зачем? =) от Moisha_Liberman

если только они не пишут какую-то свою внутреннюю реализацию, куда другой программист не полезет просто так

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

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

А кто говорит о первых реализациях STL? Или в них с тех пор никто не лазил? Стандартная библиотека это часть компилятора, её можно и нужно обновлять вместе с ним.

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

Ну если «престарелых дебилов» не тыкать носом в дерьмо, они и не поймут, где воняет.

«Престарелые дебилы», в отличии от малолетних недоумков, понимают не только где воняет, но и почему.

А вот вы начали вопить «как ужасно!» не имея ни малейшего представления почему так. И даже когда вас несколько раз тыкнули в перечень объективных причин, вы просто отмахнулись о того, чего не в состоянии понять. И продолжаете считать, что код stdlib написан так дебилами по злому умыслу.

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

Какой наивный балабол.

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

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

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

К тому же, трепло, ты опять село в лужу. Ты там выше не кукарекал «а если надо, а если не надо» - ты кукарекал, что:

как положено писать на этом языке

Вот тебе и показали, что нужно писать с unsafe - побежал писать.

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

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

Ну погоди, в хашкеле куча вещей выглядит сжато и экономично, там где в C++ начинается какой-то кошмарный ужос. Например, пресловутые пифагоровы тройки (этот пост от автора Стандарта):

// Пример программы на стандартном C++20.
// Она печатает первые N пифагоровых троек.
#include <iostream>
#include <optional>
#include <ranges>   // Новый заголовочный файл!

using namespace std;

// maybe_view создаёт вьюху поверх 0 или 1 объекта
template<Semiregular T>
struct maybe_view : view_interface<maybe_view<T>> {
  maybe_view() = default;
  maybe_view(T t) : data_(std::move(t)) {
  }
  T const *begin() const noexcept {
    return data_ ? &*data_ : nullptr;
  }
  T const *end() const noexcept {
    return data_ ? &*data_ + 1 : nullptr;
  }
private:
  optional<T> data_{};
};

// "for_each" создает новую вьюху, применяя
// трансформацию к каждому элементу из изначального ренжа,
// и в конце полученный ренж ренжей делает плоским.
// (Тут используется синтаксис constrained lambdas из C++20.)
inline constexpr auto for_each =
  []<Range R,
     Iterator I = iterator_t<R>,
     IndirectUnaryInvocable<I> Fun>(R&& r, Fun fun)
        requires Range<indirect_result_t<Fun, I>> {
      return std::forward<R>(r)
        | view::transform(std::move(fun))
        | view::join;
  };

// "yield_if" берёт bool и значение, 
// возвращая вьюху на 0 или 1 элемент.
inline constexpr auto yield_if =
  []<Semiregular T>(bool b, T x) {
    return b ? maybe_view{std::move(x)}
             : maybe_view<T>{};
  };

int main() {
  // Определяем бесконечный ренж пифагоровых троек:
  using view::iota;
  auto triples =
    for_each(iota(1), [](int z) {
      return for_each(iota(1, z+1), [=](int x) {
        return for_each(iota(x, z+1), [=](int y) {
          return yield_if(x*x + y*y == z*z,
            make_tuple(x, y, z));
        });
      });
    });

    // Отображаем первые 10 троек
    for(auto triple : triples | view::take(10)) {
      cout << '('
           << get<0>(triple) << ','
           << get<1>(triple) << ','
           << get<2>(triple) << ')' << '\n';
  }
}

Собственно внимание на эту часть:

auto triples =
    for_each(iota(1), [](int z) {
        return for_each(iota(1, z+1), [=](int x) {
            return for_each(iota(x, z+1), [=](int y) {
                return yield_if(x*x + y*y == z*z,
                    make_tuple(x, y, z));
                });
            });
        });

Што это за говнина?

А теперь в тред врывается ненавидимый тобой язык для гоев:

printNTriples :: [(Int, Int, Int)]
printNTriples = [(a,b,c) | 
                  c <- [2..], 
                  b <- [2..c-1], 
                  a <- [2..b-1], a^2 + b^2 == c^2]

main = do
  print $ take 100 printNTriples

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

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

import Control.Monad
import Control.Monad.Trans.State

select [] = []
select (x:xs) = (x, xs) : [(y, x:ys) | (y,ys) <- select xs]

pTriples :: [Integer] -> [(Integer, Integer, Integer)]
pTriples = evalStateT $ do
    a <- StateT select
    b <- StateT select
    c <- StateT select
    guard $ a <= b
    guard $ a*a + b*b == c*c
    return (a, b, c)

isTriple = not . null . pTriples

main = do
  print $ pTriples [3, 4, 9, 5]

Как это будет на C++? И кто теперь «целиком состоит из закорючек», а?

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

Опять удобное вычисление факториалов приводится как преимущество хачкеля...

Может взять уже какую-нибудь практическую задачу? Или специально не берут, т.к. там хачкель всосёт?

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

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

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

Што это за говнина?

Ну да, но зато это понятно всем, а вариант на хаскеле без примера на плюсах рядом, я бы прочесть не смог. Понятно, что это проблема моего личного неумения в хаскель, но код на большинтсве из топ 20 TIOBE я прочесть смогу, либо догадаюсь что там происходит. В случае хаскеля же что-то угадать не получится, там всё слишком тонко, закорючисто и маргинально.

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

Возможно.

Правда, я тут спорить не буду, т.к. как-то так сложилось, что студенческий код мимо проходит. Вместе со студентами.

У меня чаще другой кейс возникает. Питон, например, классный язык. Но, чуть что, «если вам нужна производительность», то... нам сюда https://docs.python.org/3/extending/building.html

Или Java под тот же android. Тоже хороший язык. Сам по себе. Но опять же. Чуть что так JNI, С или С++ в зубы и погнали. А так-то Kotlin вон придумали. Тоже развитие.

Вот и получается что как ни крутись, а один пень С или плюсы нас ждут.

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

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

Тебя поимела пропаганда.

Например, пресловутые пифагоровы тройки

Это пример не про тройки, а про последовательности. Это пример специально подобран и не является релевантным.

А теперь в тред врывается ненавидимый тобой язык для гоев:

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

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

В любой ЯП можно впихнуть ввиде скобочек любой кейс, только вот это будет работать только для этого кейса.

Оно и быстрей

В твоих фантазиях.

и красивей, чем в варианте на C++.

в твоих фантазиях.

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

Тебе уже это показывали:

generator<std::tuple<int, int, int>> triples() {
  for(auto z: iota(1))
    for(auto x: iota(1, z + 1))
      for(auto y: iota(x, z + 1))
        if(x * x + y * y == z * z)
          co_yield std::tuple{x, y, z};
}

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

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

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

Любые финансовые вычисления в банке - аналитик тебе даёт формулу, ты её загоняешь в язык и выводишь в вебморде результаты в виде графика.

Маня-фантазии. Это не вычисления.

Или например, так выглядит каждая вторая задачка в игровом движке, вся эта вычислительная геометрия, про это даже Кармак говорил.

Ну дак, где игрульки на хаскеле? Опять обосрался?

anonymous
()
Ответ на: Ага... от Moisha_Liberman

Для С наверное справедливо. Для С++... Вполне можно писать на основе материала пары-тройки книг из маст рид списка. Это никакое не погружение, а где-то поколено

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

Если честно...

То сговнокодить можно на любом языке. Это бесспорно. Но С++ временами сложнее чем С и там надо знать больше, хотя бы для того, чтобы подбирать адекватные поставленной задаче инструменты. Где-то boost, где-то stl, а где-то Qt, qml, QtQuick...

Но так же бесспорно то, что ни в С, ни в С++ не получится кодерасить... «не приходя в сознание». Тогда отровёт не то чтобы ногу, а всё, что хотя бы на сантиметр от туловища отходит. Всё поотрывает на фиг. И, кмк, это правильно. Свободы без ответственности и нет и быть не может. Свободен крутить с памятью как заблагорассудится? Ну вот и будь добр думать как лучше. Это, в конце концов, искусство как программиста. Хотя, программирование как таковое это всё таки в большеф степени не столько искусство, сколько ремесло.

Как-то вот так. Я вот так думаю, но ни в коей мере не хочу навязывать свою точку зрения. Никому. Всяк сам себе выбирает.

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

Есть задача - отделить алгоритмы от структур данных и максимизировать переиспользование. Это изначальные принципы, положенные в основу STL, которые совершенствовались с годами и привели к вещам вроде описанного мной примера. Писать вложенные for нельзя, потому что оно нарушает эти принципы, это как раз не идиоматично.

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

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

Есть задача - отделить алгоритмы от структур данных и максимизировать переиспользование.

Что за маня-истории? У кого и где такая задача и причём тут твоя портянка на хаскеле вообще?

Это изначальные принципы, положенные в основу STL, которые совершенствовались с годами и привели к вещам вроде описанного мной примера.

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

Если бы ты хотел реально сравнивать - ты не пытался манипулировать, а реализовал бы на крестах свой маня-сахар. Но ты решил врать.

Я тебе уже показал императивный код, но ты сразу убежал и решил проигнорировать. Почему ты так сделал?

Трюк не в том, чтобы «генерить последовательность», а чтобы выделить алгоритм отдельно, это куда более масштабная идея.

Где в твоей хаскель-дристне алгоритм отдельно? Опять врёшь. Это именно генерация последовательности, которая никому нахрен не упёрлась. Именно потому, что пойдя в реальные кейсы - от твоих маня-примеров останется только пердёжь в лужу.

Например, он означает, что вообще весь код превращается в вызов ленивых вычислений (которые да - в результате выстроятся в ленивую последовательность, но не только).

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

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

В фантазиях твоих он будет так выглядеть. Ты взял убогую задачку из лабы, наклал нелепой херни и сравниваешь тонны сахара и портянки. Пиши сахар, сравнивай.

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

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

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

Царь не полюбил С++, хотя в районе 17 крестов признал, что на них стало возможно писать. Я просто воен справедливости.

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

У кого и где такая задача

у рашен хакера Александра Степанова, придумавшего богоподобный C++ STL (всего лишь богоподобный, то есть подобный богу, а не являющийся им, если ты понимаешь, о чём я :) ), а STL есть сердце и суть C++, дурилка ты картонная ;)

co_yield

это кстати интересный вопрос, корутины таки решили завезти в 20 или нет?

, а реализовал бы на крестах свой маня-сахар.

мой маня-сахар уже реализован, пример выше - это готовая реализация, которая абсолютно точно войдёт в C++20, а до этого распространяется в виде сторонней библиотеки, попробовать кою ты можешь уже прямо сейчас :)

если хочешь сохранить пост царя скилледов, теперь тебе нужно подтвердить право на царствование путём унижения Эрика Ниблера, который всё это дело написал

(у меня там правда ещё целая толпа авторов стандарта, да и у Ниблера это не единственная тема, но хорошего по немножку!)

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

у рашен хакера Александра Степанова

Пруфы.

это кстати интересный вопрос, корутины таки решили завезти в 20 или нет?

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

мой маня-сахар уже реализован, пример выше - это готовая реализация, которая абсолютно точно войдёт в C++20, а до этого распространяется в виде сторонней библиотеки, попробовать кою ты можешь уже прямо сейчас :)

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

Твой маня-подлог заключается в том, что ты(либо не ты) взял сахарный кейс для твоего недоязычка и сравнил с обобщённым крестовым решением.

если хочешь сохранить пост царя скилледов, теперь тебе нужно подтвердить право на царствование путём унижения Эрика Ниблера, который всё это дело написал

Опять трепло прячется за кем-то? Во-первых, что это за нонейм? Во-вторых, с чего вдруг его «мнение» чего-то стоит? Хочешь унижения - давай, организовывай. Я тебе выкачу ответ на его потуги, а ты там будешь ему в твитер спамить, хорошо? Возможно он поможет тебе ответить мне.

(у меня там правда ещё целая толпа авторов стандарта, да и у Ниблера это не единственная тема, но хорошего по немножку!)

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

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

Не, я почитал его портянку - он же поехавший и тотальной бездарный. Собирает код шлангом, измеряет время сборки мусорной говнолибы, измеряет время выполнения клоком(В 20крестах), не осилила printf() - нелепость этих потуг меня так удивляет. Откуда ты выкопался этот клоун?

Вот она, суть:

var triples =
    from z in Enumerable.Range(1, int.MaxValue)
    from x in Enumerable.Range(1, z)
    from y in Enumerable.Range(x, z)
    where x*x+y*y==z*z
    select (x:x, y:y, z:z);
var triples = Enumerable.Range(1, int.MaxValue)
    .SelectMany(z => Enumerable.Range(1, z), (z, x) => new {z, x})
    .SelectMany(t => Enumerable.Range(t.x, t.z), (t, y) => new {t, y})
    .Where(t => t.t.x * t.t.x + t.y * t.y == t.t.z * t.t.z)
    .Select(t => (x: t.t.x, y: t.y, z: t.t.z));

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

К тому же, ты опять всё перепутал(как и тот клоун). В крестовых лямбдах скобчки используются не просто так, ведь это кресты, а не твоя мусорный недоязычок с ГЦ. Мне послать тебя делать на недоязычке то, что могут делать кресты? Либо того клоуна послать? Ты ему напиши в твитере, спроси.

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

а также кроссплатформенный (что выливается в слишком мощные макросы)

Дай номер дилера, а.

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

обожает пердолиться в C++17, обмазываясь функциональщиной в нём и обильно посыпая всё лямбдами

Лямбды уже в C++11 были и сейчас только в легаси и старперами не используются, но даже гайдлайнс для некоторых эмбеддед уже C++14 во всю используют.

На повестке дня новые горизонты: рейнджи, концепты, контракты. Похороны C++ переносятся на неопределённый срок.

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

Ну т.е. те фичи, которые в других языках были ещё 20-30 лет назад, в C++ только сейчас заносят. Наверняка, как всегда через задницу, ради обеспечения обратной совместимости с древними диалектами C, которая сейчас никому нахрен не всунулась.

Можно лучше модули хотя бы сначала сделать? А то совсем как-то стыдно.

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

Это какой, интересно, в '97м году был ЯП, компилируемый, со всеми фичами, принятыми в C++20? Или как по Гоголю, «если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича» ...

А то совсем как-то стыдно.

Программирование - не конкурс красоты.

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

Ну т.е. те фичи, которые в других языках были ещё 20-30 лет назад, в C++ только сейчас заносят.

Это в каких нативных языках без GC лямбды, constexpr и variadic templates были 30 лет назад?

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

Существует множество таких языков.

anonymous
()

Ты хотел написать «про то, как развидеть C++»?

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

Вообще-то, не совсем так.

те фичи, которые в других языках были ещё 20-30 лет назад, в C++ только сейчас заносят.

Если даже говорить о С, то в 1997г. в Addison-Wesley вышла книга под названием «Functional C». Если надо, то обмазаться с ног до головы можно здесь https://research.utwente.nl/files/5128727/book.pdf. Тут версия 6.8 данной книги. Так что, всё что нужно, уже занесли. И давно. Другое дело, что не стали добавлять в стандарт, т.к. кому-то всё это нужно, а кому-то нет. Хотя, лично мне кажется что отдельные идеи из парадигмы ФП просто обязаны в ряде случаев использоваться программистом. Как минимум, он должен предпринимать действия для уменьшения side effect тогда проблем с потокобезопасностью будет меньше (ну чисто примера ради).

Хотя, и gcc тоже развивается. Например, для чистых функций уже ввели attribute ((_pure__)). Т.е., если возвращаемый результат ф-ии не имеет side effect и зависит от глобальных переменных или своих аргументов, то такая ф-я может быть помечена как чистая и оптимизатор gcc займётся ею отдельно.

Заносить это всё и чохом в стандарт языка? А зачем? Кому-то пригодятся green threads, а кто-то пищит от корутинов. Хотя, язык как таковой позволяет иметь реализации и того и другого, но только для своих, частных случаев. Надо? Ну так напишите и используйте или используйте уже написанное (гуглится и то и другое).

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

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

Плюсы, значит, стрёмные

Именно.

а хаскель, целиком состоящий из закорючек, норм

В хаскеле не так много закорючек, зато да, есть user-defined операторы, что очень удобно.

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

Не загоняйся, это я спетросянил, учитывая широкий смысл слова «приняли».

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

«О боже мой, я не знаю Haskell, который не использует C-like синтаксис, поэтому буду говорить, что СЛОЖНА»

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

От Haskell как раз таки очень мало. HKT нет, кастомных операторов нет, композировать функции можно, но неудобно, аналогично с каррированными функциями, SYB разве что на макросах костылить.

~~@~~

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