Кто-то еще верит, что C/C++ не для криворуких макак?

Кино и онлифанс забыл.

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

Если хочется получить признание, то надо работать с людьми, а не машинами, вот такие дела.

Прекрати меня убеждать в том, с чем я согласен!

Самое главно: «это» решает проблемы бизнеса быстрее и дешевле. Потому и популярно.

Все профессии нужны, все профессии важны.

Пусть программисты пишут AWS Glue и другие тулы, а датасайнтисты пусть пишут свои кривые скриптики. Бизнес доволен - у всех есть работа.

Это позволяет бизнесу быстро и эффективно пилить бабки, таки да. Поэтому оно и популярно.

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

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

Вы основываете свое суждение на каких-то данных или только на личных наблюдениях?

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

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

Если хочется получить признание, то надо работать с людьми, а не машинами, вот такие дела.

Расскажи это создателю Биткойна.

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

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

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

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

Кастуй, расскажем.

Расскажи это создателю Биткойна.

Ты же сам даже имя его не вспомнил ггг. Что и кому еще надо рассказывать?

Тебе шашечки или ехать? Можно быть одновременно известным и неизвестным. Или ты думал так только в квантовом мире происходит?

Тебе шашечки или ехать?

Мне ехать с шашечками.

Можно быть одновременно известным и неизвестным.

Нет.

Да, паскаль читать проще. Но паскаль не может выразить и 10% того, что можно выразить на С++. При этом С++ читать вовсе не в 10 раз сложнее.

Так а в чем сложность крестов? Действительно интересно услышать мнение человека, которому вот такое норм:

template<typename T>
struct HasBarOfTypeInt<T, TypeSinkT<decltype(std::declval<T&>().*(&T::bar))>> :
    std::is_same<typename std::decay<decltype(std::declval<T&>().*(&T::bar))>::type,int>{};

А Тео? Рейзер? Кармак? Илон мать его Маск? Возняк? Да Дуров жеж!

А Тео? Рейзер? Кармак? (...) Возняк?

Это известность в рамках айтишной песочницы. МакКузика вспомни еще.

Илон мать его Маск?

Я только щас, слазив в гугло, узнал, что Маск еще и немножечко шил^Wкодил. Известен он ну никак не этим.

Да Дуров жеж!

О, Дуров, пожалуй, известен как программист.

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

Это известность в рамках айтишной песочницы

А надо среди кого? Среди инстамоделей? или заводчан? Или депутатов парламента какой-нибудь страны?

Среди инстамоделей? или заводчан? Или депутатов парламента какой-нибудь страны?

Ну эээ да, и так далее. Вон, Дурова знают же. Сраного Митника знали вне ойтишной тусы.

Для начала предлагаю выразить это на паскале.

Далее. Прочитать этот код вовсе несложно. Единственным затруднением для новичка может оказаться синтаксис pointer-to-member, который попросту встречается крайне редко относительно других указателей на что-то.

В коде приведено определение специализации шаблона HasBarOfTypeInt по второму шаблонному параметру типом TypeSinkT, параметризованным типом указателя на поле T::bar примененного к экземпляру T&. Специализация публично наследуется от std::is_same, параметризованного типом std::decay<...>::type, в свою очередь параметризованного… и так далее. Это консистентный и простой синтаксис языка.

Сложность здесь состоит в том, чтобы понять, что смысл, заложенный в этом коде – вовсе не какие-то специализации каких-то структурок, а проверка типа на наличие публично доступного поля bar, из которого можно по крайней мере прочитать int. В эту сторону подсказывает название типа, но не более. Для того, чтобы знать, как и почему этот код будет работать, нужно знать про SFINAE.

Вот в этом и заключается сложность С++. Это гибкий язык, для того, чтобы знать который мало уметь его читать – нужно еще и знать ряд идиом языка. Но к грамматикам, с которыми героически сражается Владимир, никакого отношения это не имеет.

Кстати, в С++20 для получения примерно того же самого достаточно писать

namespace detail { std::decay<T> decay(T&&); };

template <typename T>
concept HasBarOfTypeInt = requires (T& t) { { detail::decay(t.bar) } -> std::same_as<int>; };

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

Но к грамматикам, с которыми героически сражается Владимир, никакого отношения это не имеет.

Просто вы «не в теме».

Тема разработки компиляторов для меня близка и опыт в разработке имеется.

Прочитать этот код вовсе несложно

#include<stdio.h>
int main(){int a=0,b=a;long long c[178819],d=8,e=257,f,g,
h,i=d-9;for(;a<178819;){c[a++]=i;}for(a*=53;a;a>>=8)putc\
har(a);if((f=getchar())<0)return 0;for(;(g=getchar())>=0;
){h=i=g<<8^f;g+=f<<8;a=e<(512<<a%8|(a<7))||f>256?a:a>6?15
:a+1;for(;c[i]>-1&&c[i]>>16!=g;)i+=i+h<69000?h+1:h-69000;
h=c[i]<0;b|=h*f<<d;for(d+=h*(a%8+9);d>15;d-=8)putchar(b=b
>>8);f=h?g-f*256:c[i]%65536L;if(a<8*h){c[i]=g*65536L|e++;
}}b|=f<<d;for(d+=a%8;d>-1;d-=8)putchar(b>>=8);return!53;}

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

Не позорься.

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

Так я и говорю: отжиматься от пола с хлопком за спиной несложно. Просто нужно сперва позаниматься этим несколько лет.

namespace detail { std::decay<T> decay(T&&); };

Так. Уже здесь к тебе подходит обычный живой человек и говорит: что это? Откуда здесь берется T? Это объявление функции, да? А где тело?
Охренеть синтаксис. Перл себе такого не позволял, а все равно сдох.

Просто очень хотелось бы иметь крестовое IDE, которое детектило бы попытку написать такие вот `&>().*(&T::bar))>::` последовательности символов и немедленно стреляло бы кодеру из двустволки в лицо.

Кто-то еще верит, что C/C++ не для криворуких макак?

Фото есть?

Откуда здесь берется T?

T берется из template <typename T>, которое я пропустил по ошибке. Кстати именно template и typename часто оказываются причиной для критики – в других языках достаточно написать foo<T>(). Всем не угодишь.

А где тело?

А тела здесь нет, потому что оно не требуется для выведения.

Перл себе такого не позволял, а все равно сдох

А сишка позволяет. Но это неважно. Позволяет паскаль – тот самый паскаль.

Просто очень хотелось бы иметь крестовое IDE, которое детектило бы попытку написать такие вот &>().*(&T::bar))>:: последовательности символов и немедленно стреляло бы кодеру из двустволки в лицо.

Тебя Столяров покусал?

такие вот &>().*(&T::bar))>:: последовательности символов и

Не позорься. Ты выдрал кусок текста так, что он не имеет смысла – и теперь он не имеет смысла.

Не позорься.

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

Т.о. на примере данного кода можно понять только то, что С++ стал читаем только через 20 лет после появления шаблонов и SFINAE.

Нет. SFINAE стал читаем через 20 лет после открытия SFINAE. От того, что SFINAE сложно читать, условное

struct A : public B {
    int x;
    int y();
};

читать сложнее не стало.

Какие проблемы у тебя со сложными конструкциями языка?

На других языках эти идеи даже не выражаются, а в С++ они выражаются сложно.

Просто не пользуйся этим как программисты на других языках и всё. Простые конструкции и в С++ просты.

Какие проблемы у тебя со сложными конструкциями языка?

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

Такие же, как у всех.

А какие у всех проблемы? Ты не ответил зачем ты используешь эти конструкции? В паскале их нет. Представь что их нет и в С++.

А какие у всех проблемы?

Ну вот ты и скажи мне, раз ты сам употребил слово «сложные».

Представь что их нет и в С++.

Представил. Потом открыл код - а они все равно есть!

опытные плюсовики, которые уже поняли, что плюсы - не ЯП будущего, исследуют другие варманты. Например, Chandler Caruth, спец. по плюсам, ллвм и ко в Гугл, экспериментирует с новым ЯП карбон как с эдаким «C++ минус попаболь». А так уже давно есть например Swift, новые версии которого доступны под пермиссивной лицензией.

Ну вот ты и скажи мне, раз ты сам употребил слово «сложные».

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

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

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

Например, Chandler Caruth, спец. по плюсам, ллвм и ко в Гугл, экспериментирует с новым ЯП карбон как с эдаким «C++ минус попаболь».

Ну, видимо, он ещё с 2019 забил на плюсы, как и сам Гугл.

Если не считать 1 коммит в 2020 и 4 коммита в 2021

https://github.com/llvm/llvm-project/commits?author=chandlerc

Люди приходят и уходят.

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

Просто не пользуйся этим как программисты на других языках и всё. Простые конструкции и в С++ просты.

Хитровывернутые шаблоны действительно не часто нужны, а когда нужны, то можно в Интернете найти. Но, например, какой-нибудь полиморфизм использовать будет сложнее, чем в Python или C#. Потому что надо будет явно создавать объект в куче, а затем его руками удалять или через умный указатель. Хотя не уверен, что в Паскале с этим проще.

Но, например, какой-нибудь полиморфизм использовать будет сложнее, чем в Python или C#. Потому что надо будет явно создавать объект в куче, а затем его руками удалять или через умный указатель.

Не вижу однозначной связи между полиморфизмом и кучей.

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

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

// pointers to base class
#include <iostream>
using namespace std;

class Polygon {
  protected:
    int width, height;
  public:
    void set_values (int a, int b)
      { width=a; height=b; }
};

class Rectangle: public Polygon {
  public:
    int area()
      { return width*height; }
};

class Triangle: public Polygon {
  public:
    int area()
      { return width*height/2; }
};

int main () {
  Rectangle rect;
  Triangle trgl;
  Polygon * ppoly1 = &rect;
  Polygon * ppoly2 = &trgl;
  ppoly1->set_values (4,5);
  ppoly2->set_values (4,5);
  cout << rect.area() << '\n';
  cout << trgl.area() << '\n';
  return 0;
}

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

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

Однозначной связи между полиморфизмом и кучей нет в простейших примерах из учебника.

Её и в реальной разработке нет.

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

С чего бы? Я Вам запросто на стеке instance создам и отдам pointer-to-the-base куда-то там. Делов то.

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

Хех. Вы видите принципиальную разницу?

Её и в реальной разработке нет.

Для того, чтобы так утверждать, надо собрать какую-то статистику. Пока у нас Ваше слово против моего. Ну можно по тем же GoF пройтись, хотя бы.

С чего бы? Я Вам запросто на стеке instance создам и отдам pointer-to-the-base куда-то там.

Ок. Покажите код фабрики, где объект в стеке создаётся.

Вы видите принципиальную разницу?

Да. Я должен помнить, где использую сам объект, а где указатель.

Нашёл пример с Factory Method, который ближе к практике:

#include <iostream>
#include <vector>
  
enum Warrior_ID { Infantryman_ID=0, Archer_ID, Horseman_ID };
  
// Иерархия классов игровых персонажей
class Warrior
{
  public:
    virtual void info() = 0;     
    virtual ~Warrior() {}
    // Параметризированный статический фабричный метод
    static Warrior* createWarrior( Warrior_ID id );
};
  
class Infantryman: public Warrior
{
  public:
    void info() { 
      cout << "Infantryman" << endl; 
    }
};
  
class Archer: public Warrior
{
  public:
    void info() { 
      cout << "Archer" << endl; 
    }
};
  
class Horseman: public Warrior
{
  public:    
    void info() { 
      cout << "Horseman" << endl; 
    } 
};
  
  
// Реализация параметризированного фабричного метода
Warrior* Warrior::createWarrior( Warrior_ID id )
{
    Warrior * p;
    switch (id)
    {
        case Infantryman_ID:
            p = new Infantryman();           
            break;      
        case Archer_ID:
            p = new Archer();           
            break;
        case Horseman_ID:
            p = new Horseman();           
            break;              
        default:
            assert( false);
    }
    return p;
};
  
  
// Создание объектов при помощи параметризированного фабричного метода
int main()
{    
    vector<Warrior*> v;
    v.push_back( Warrior::createWarrior( Infantryman_ID));
    v.push_back( Warrior::createWarrior( Archer_ID));
    v.push_back( Warrior::createWarrior( Horseman_ID));
  
    for(int i=0; i<v.size(); i++)
        v[i]->info();
    // ...

Метод createWarrior возвращает ссылку на объект в куче. Можно как-то изменить пример, чтобы объекты создавались в стеке?

Можно как-то изменить пример, чтобы объекты создавались в стеке?

Placement new().

PS. А в вашем случае (sizeof is the same) - так вообще всё тривиально разруливается, хотя и по канонам - неправильно так делать.

Да. Я должен помнить, где использую сам объект, а где указатель.

Спешу Вас расстроить - reference это decayed pointer, ни больше ни меньше.

Placement new().

То есть ещё усложним пример для понимания?