А был ли мальчик? (помянем плюсы)

[AndreyT]

Cо вторым примером понятно, а в чем фишка первого?

Фишка? обьяснить что перед нами статический ассерт.

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

[Prosche]

Cо вторым примером понятно, а в чем фишка первого?

Фишка? обьяснить что перед нами статический ассерт.

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

Спасибо за ваше мнение.

[AndreyT]

Куриоз был.

Автор прав: "this makes a const lvalue reference able to do everything a const rvalue reference can and more". На этом можно было остановиться, но никто не гарантирует, что завтра кто-нибудь не придумает какой-то новой идиоматической семантики для rvalue references на основе уже существующих правил overload resolution.

Все мы понимаем, что rvalue references разрабатывались для move semantics и perfect forwarding. Однако в глубинах стандартной библиотеки вы можете найти и такое С++11 нововведение

Code: Select all

template< class CharT, class Traits, class T >
basic_ostream< CharT, Traits >& operator<<( basic_ostream<CharT,Traits>&& os, const T& value );

Здесь нет ни move semantics, ни perfect forwarding. Здесь rvalue reference использовано совсем для другой цели - чтобы закрыть пресловутый "парадокс" С++: для временных объектов разрешается вызывать неконстантные методы, но к ним не разрешается привязывать неконстантные lvalue references. В результате до С++11 вот в таком коде

Code: Select all

int main() 
{
  std::ostringstream() << std::string("Hello") << 123; // Error в C++98/C++03
  std::ostringstream() << 123 << std::string("Hello");
}

корректной являлась только вторая строка вывода. Начиная с С++11 корректны обе, именно благодаря вышепроцитированному объявлению. Опять же, этому нишевому использование rvalue references тоже никак не нужны const rvalue references. Но кто его знает, что там еще придумают в будущем?

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

Спасибо за ваше мнение.

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

[valchkou]

а кто в наши дни продвигает и развивает плюсы? если такое вообще имеет место быть

[Medium-rare]

Раз оригинальный заголовок, то почему бы не задать оригинальный вопрос? Ну вот, ничего же мимо нас не пройдёт. Вдруг.
Комитет: https://isocpp.org/std/the-committee. Если они там не просто прикидываются типа умными в наши-то дни.

[Medium-rare]

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

[oshibka_residenta]

а кто в наши дни продвигает и развивает плюсы? если такое вообще имеет место быть

Очевидно, есть узкие ниши, где C++ - лучший вариант. Например, где по производительности всякие Java не проходит, а на чистом C монстр получается.
Конечно, и это видно даже из данного топика, если можно обойтись Java/C# или python, то их и нужно использовать.

[tau]

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

Я, в общем-то, пытался сказать про то, что С++, в его текущей инкарнации, довольно сложен для понимания и изучения. И ничего с этим не поделаешь.
То есть, если надо просто пользоваться STL, то оно-то несложно, конечно, тем более что теперь все нужные конструкции являются встоенной частью языка теперь. Я и сам пользуюсь вовсю, даже на iOS. Но вот все эти мелкие проблемы отравлют жизнь. Вот, скажем, тут выше кусок кода приводили с вопросом, какой из конструкторов будет вызван. Так вот, даже у эта микроскопическая ситуация может иметь разные ответы в зависимости от контекста:
- вызов func(a) будет отличаться от вызова auto b = func(a).
-а что будет, если func(a) находится в другом файле и компилируется отдельно.
-а что будет, если данная функция была скомпилирована хрен знает чем и теперь в lib файле.

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

Сказав всё это, я, всё-таки, С++ люблю нежной любовью. Вот сейчас проектриую всякое для DirectX, так там кроме С++ никакого выбора и нету. А так бы мне тоже хотелось надрать из энтернета чего-то модного на java script, слепить быстренько и продать кому-нибудь, пока оно не развалилось. И, как в песне пелось, "и всю жизнь получать гонорар".
Но не получается.

[OtherSide]

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

[tau]

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

[Medium-rare]

Сказав всё это, я, всё-таки, С++ люблю нежной любовью. Вот сейчас проектриую всякое для DirectX, так там кроме С++ никакого выбора и нету.

Почему не OpenGL? Вопрос риторический. Хорошо, что мы не самые прикладные прикладники, и тем более, не сисадмины. Хотя, безусловно, они тоже нужны, но ещё всякое ведь пишут, преимущественно, рабинович им напел.

[tau]

Сказав всё это, я, всё-таки, С++ люблю нежной любовью. Вот сейчас проектриую всякое для DirectX, так там кроме С++ никакого выбора и нету.

Почему не OpenGL? Вопрос риторический. Хорошо, что мы не самые прикладные прикладники, и тем более, не сисадмины. Хотя, безусловно, они тоже нужны, но ещё всякое ведь пишут, преимущественно, рабинович им напел.

И OpenGL тоже, почему же нет. Точнее, и то и то, поскольку портирую с OpenGL/iOs на DirectX/Win.
Я с обоими работаю, с короткими перерывами, уже лет хрен знает сколько. Уже 15, наверное.
На каком ещё языке это можно делать, кроме С/C++.

[Medium-rare]

И OpenGL тоже, почему же нет. Точнее, и то и то, поскольку портирую с OpenGL/iOs на DirectX/Win.
Я с обоими работаю, с короткими перерывами, уже лет хрен знает сколько. Уже 15, наверное.
На каком ещё языке это можно делать, кроме С/C++.

Qt даст вам OpenGL для разных платформ, включая Windows. Ещё это можно вполне "делать" на Qt/QML, он просто вызывает код из готовых C++ компонентов. И там пожалуйста, с натяжкой, но вполне, можно сказать, смотрите, на JavaScript что делают! Ну, раз он живёт в QML. Сейчас в Qt Creator вполне можно сделать QML/JavaScript аппликуху без единой вашей строчки на C++. И она ещё как может чегой-то творить с OpenGL. Строго говоря, C++ предоставляет API для OpenGL surface. А "сделали" surface, ну, спроецировали некую область памяти современного видоадаптера на своё окно, вывели хоть в Питон, и понеслась. Фундаментально там shading language. С этой точки зрения и C++ ни при чём.

[Pantigalt]

Феерический топик, вначале хотел "рвать и метать", а потом решил, что он показательный, в реальной жизни народ так же мнит что знает плюсы, а по факту такая ахинея из под пера выходит.
Элементарную вещь спросишь, сидят, не вдупляют. Вот например, что делает этот код? (вопрос риторический, не надо отвечать), ведь классика:

Code: Select all

template <bool b>
struct А {};
template <>
struct А<true>
{
    static void a() {}
};

Добрая половина знатоков плюсов отвалится.
А 0х11 и выше это вообще вышка, народ просто ничего не втыкает. У меня тут эпик фейл приключился. Сведу пример к простейшему:

Code: Select all

    struct A
    {
        A() {};
        A(A&&)
        {
           std::cout << "Move constructor";
        }
        A(const A&)
        {
            std::cout << "Copy constructor";
        }
    };
    A&& func(A& a)
    {
        return std::move(a);
    }
int main(int argc, const char * argv[])
{
    A a;
    func(a);
    return 0;
}

Вот эта тривиальная вещь порвала мозг всем. Вопрос был, что выведется в консоль?
Старики заявили, что копи конструктор, "продвинутая" молодежь, что "конечно же мув". О том, что не выведется ничего не допер НИКТО.
Так что не было никакого мальчика, умер еще при родах. Язык остался не понятым подавляющим большинством пользователей.

Проблема в том что люди книжки не читают, например Майерса про C++ 11. Там про RV хорошо описано.

[tau]

Qt даст вам OpenGL для разных платформ, включая Windows.

Я пробовал всякое, за многие годы, и в различных позах. В результате - выкинул всё это и пользуюсь напрямую API. Считаю, что это мне экономит время и нервые клетки. Все остальные, разумеется, могут пользоваться чем хотят. Я - за разнообразие.