Здравствуйте, Ip Man, Вы писали:

IM>По-моему, комитету С++ пора на каникулы. Лет так на 10.
Тут не только комитету пора на каникулы. В соседней теме местные завсегдатаи на серьёзных щщас нахваливают откровенное говнище и оценочки друг дружке ставят: http://rsdn.org/forum/cpp/7741209

Автор: Коваленко Дмитрий
Дата: 28.05.20

Клоунада да и только, рсдн уже не торт.

Здравствуйте, smeeld, Вы писали:

S>> С древней кодобазой, на 80% состоящей из велосипедов в которых уже никто не разбирается.
S>99% всех промышленных программных систем, обсуживающих мир, представлено именно этим кодом.

Система, занимающая примерно 40% всего рынка SCADA и до 90% рынка систем управления питанием для общественных зданий и датацентров, написана на плюсах (c применением boost) и сишарпе.

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

S>А всякие хеллоуворлды даром никому не нужны, на каком бы распрекрасном C++ они не были написаны.

Здравствуйте, so5team, Вы писали:


S>Envoy же является примером производительного решения, которое написано как раз на современном C++.

Пользуясь случаем спрошу как в современном С++ сделать опережающее описание вложенного класса?

Здравствуйте, Kluev, Вы писали:

K>Пользуясь случаем спрошу как в современном С++ сделать опережающее описание вложенного класса?

Ответ будет зависеть от того, что вы понимаете под "опережающее описание вложенного класса" и того, зачем вам это нужно.
Но, есть подозрение, что выглядеть будет почти так же, как и в C++98, только вместо typedef будет использоваться using.

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Kluev, Вы писали:

K>>Пользуясь случаем спрошу как в современном С++ сделать опережающее описание вложенного класса?

S>Ответ будет зависеть от того, что вы понимаете под "опережающее описание вложенного класса" и того, зачем вам это нужно.

struct Foo; // поехали
struct Foo::Bar; // приехали

struct Foo
{
    struct Bar
    {
    };
};

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

Здравствуйте, Kluev, Вы писали:

K>

K>struct Foo; // поехали
K>struct Foo::Bar; // приехали
K>

И где это нужно? Ну, за исключением кидания какашками на форуме?

K>Со времен си с классами не могут исправить.

Так ведь не сломано ничего. Исправлять незачем.

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Kluev, Вы писали:

K>>

K>>struct Foo; // поехали
K>>struct Foo::Bar; // приехали
K>>

S>И где это нужно? Ну, за исключением кидания какашками на форуме?

Грубо говоря весь С++ это собрание ненужных и недоделанных вещей. Но речь не об этом. В язык ввели вложенные классы как минимум с С++98. И 20 чертовых лет не могут сделать для них опережающее описание (forward declaration) чтобы ими можно было полноценно пользоваться.

Здравствуйте, Kluev, Вы писали:

S>>И где это нужно? Ну, за исключением кидания какашками на форуме?

K>Грубо говоря весь С++ это собрание ненужных и недоделанных вещей. Но речь не об этом.

Если речь не об этом, то зачем вы вновь это повторяете?

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

K>В язык ввели вложенные классы как минимум с С++98. И 20 чертовых лет не могут сделать для них опережающее описание (forward declaration) чтобы ими можно было полноценно пользоваться.

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

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

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

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Kluev, Вы писали:

S>>>И где это нужно? Ну, за исключением кидания какашками на форуме?

K>>Грубо говоря весь С++ это собрание ненужных и недоделанных вещей. Но речь не об этом.

S>Если речь не об этом, то зачем вы вновь это повторяете?

А что нельзя?

S>Грубо говоря, у вас цель донести до окружающих свое мнение о том, что C++ говно. Спасибо, но не нужно. Во-первых, вы не оригинальны. Во-вторых, ваше мнение не интересно. В-третьих, высказывание этого факта ничего не меняет.

Знаете, переход на личности еще можно оправдать в возрасте до 30. Дальше это инфантилизм.

S>О каком полноценном использовании вы говорите, если вы даже не можете одного простого примера того, где это было бы реально нужно, привести не можете?

S>По сути же вложенные классы были в языке еще до C++98. И до появления в языке пространств имен использование вложенных классов имело большой смысл, т.к. объемлющий класс выступал в качестве пространства имен. Соответственно, вложенные классы помогали избежать засорения глобального пространства имен.

S>Но после того, как в языке повсеместно стали доступны пространства имен, надобность во вложенных классах сильно снизилась. И очень тяжело найти примеры того, где бы опережающее объявление вложенного класса было бы нужно. И где бы нельзя было выйти из ситуации с помощью вспомогательных пространств имен.

А где реально нужны пространства имен? Приведите хоть один реальный случай случая когда нельзя было бы обойтись префиксами. Новшества вводят для удобства, а не только когда реально нужно. Кроме того forward declaration для вложенных классов это тот случай когда исправлять реально нужно, потому что это баг на уровне языка.

Здравствуйте, Kluev, Вы писали:

S>>Если речь не об этом, то зачем вы вновь это повторяете?

K>А что нельзя?

Формально запретов нет. Но в этом повторении нет ни смысла, ни пользы. Посему вы зря тратите и свое, и чужое время.

S>>Грубо говоря, у вас цель донести до окружающих свое мнение о том, что C++ говно. Спасибо, но не нужно. Во-первых, вы не оригинальны. Во-вторых, ваше мнение не интересно. В-третьих, высказывание этого факта ничего не меняет.

K>Знаете, переход на личности еще можно оправдать в возрасте до 30. Дальше это инфантилизм.

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

K>А где реально нужны пространства имен?

Везде, что хоть сколько-нибудь отличается от студенческой лабораторной.

K>Приведите хоть один реальный случай случая когда нельзя было бы обойтись префиксами.

Попробуйте выразить std::chrono::milliseconds через префиксы. Или std::chrono::steady_clock::time_point. А так же попробуйте придумать на префиксах адекватную замену для, например, using namespace std::chrono_literals.

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

K>Новшества вводят для удобства, а не только когда реально нужно.

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

K>Кроме того forward declaration для вложенных классов это тот случай когда исправлять реально нужно, потому что это баг на уровне языка.

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

Здравствуйте, lpd, Вы писали:

S>>Не, так не пойдет. Дайте, пожалуйста, ссылку на конкретный фрагмент кода.
lpd>Ну вот тебе большая функция-кошмар плюсовика: kvm

Зачем там goto out; если можно просто написать return r; ?
Почему функция возвращает int, а не bool?
Почему r не инициализирована при объявлении? Экономим? Тогда почему прямо не возвращать константы через return?

__builtin_expect — это вообще за рамками языка С. А вот в С++ это вроде бы добавили [likely]] / [unlikely]] (никогда не пользовался).

Здравствуйте, so5team, Вы писали:

K>>Знаете, переход на личности еще можно оправдать в возрасте до 30. Дальше это инфантилизм.

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

Я конечно в курсе что в С++ нет рефлексии, но это качество каждый может развить у себя самостоятельно.

K>>А где реально нужны пространства имен?

S>Везде, что хоть сколько-нибудь отличается от студенческой лабораторной.

Смешно, но именно из студенческих лабораторий мелкобуквенная метастаза попала прямо в стандарт С++. Например iostream. По словам Страуструпа была написанная кем-то на спор. Или stl. Минуя продакшн сразу в стандарт.

K>>Приведите хоть один реальный случай случая когда нельзя было бы обойтись префиксами.

S>Попробуйте выразить std::chrono::milliseconds через префиксы. Или std::chrono::steady_clock::time_point. А так же попробуйте придумать на префиксах адекватную замену для, например, using namespace std::chrono_literals.

Да в легкую. Например std_chrono_milliseconds. Можете возразить, что длинно, но до auto stl-юзеры писали километровые std::map<..........., ...........>::const_iterator и не потели. Что касается литералов, то это фантастически бесполезная лабуда. Кто вообще их просил делать это? Люди ждут десятилетиями рефлексию, модульность, исправление дыр в языке и т.п, вместо этого комитет выпускает "литералы". Ей Богу хочется покрутить пальцем у виска.

S>А еще лучше, поскольку вы вроде как всерьез заговорили про префиксы, постарайтесь хоть чем-нибудь доказать, что на вас стоит тратить время. Что вы не форумный тролль и что имеете отношение к разработке запускаемого в продакшен софта. Особенно софта, который затем будете дорабатывать и эксплуатировать не вы.

Вы опять на личности хотите перейти? Развивайте рефлексию. В С++ мы ее все равно не дождемся


K>>Новшества вводят для удобства, а не только когда реально нужно.

S>Именно так C++ пока и развивается. Но если ваша цель -- это лишний раз заявить, что C++ говно, то вы вряд ли это замечаете.

K>>Кроме того forward declaration для вложенных классов это тот случай когда исправлять реально нужно, потому что это баг на уровне языка.

S>Пока вы не смогли привести ни одного примера, где бы этот баг проявлялся в полный рост. И просить, видимо, бесполезно, т.к. ваша цель -- это лишний раз завить, что C++ говно.

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

Здравствуйте, lpd, Вы писали:

lpd>Ну вот десятки лет пока умные указатели не встроили в С++, все (в том числе программисты получше Страуструпа и других С++ников) знали про умные указатели, и почти никто ими не пользовался, кроме как когда они реально были нужны для учета ссылок.

Это не так. Фактически умные указатели (ака ресурсы с подсчётом пользователей) были придуманы и использовались задолго до шаблонного синтаксиса в С++. В С++ умные указатели широко использовались в коммерческом софте начиная где-то между 1995-2000 годах.

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, lpd, Вы писали:

lpd>>Ну вот десятки лет пока умные указатели не встроили в С++, все (в том числе программисты получше Страуструпа и других С++ников) знали про умные указатели, и почти никто ими не пользовался, кроме как когда они реально были нужны для учета ссылок.

BFE>Это не так. Фактически умные указатели (ака ресурсы с подсчётом пользователей) были придуманы и использовались задолго до шаблонного синтаксиса в С++. В С++ умные указатели широко использовались в коммерческом софте начиная где-то между 1995-2000 годах.

Я в курсе, перечитай что цитируешь.

Здравствуйте, lpd, Вы писали:

CK>>то что мы можем писать свой код в деструкторе, это тоже так совпало и хак чистой воды? если следовать твоей логике, то писать деинициализацию в деструкторе — хак чистой воды, поэтому класс MyFile должен иметь метод destroy, который нужно явно вызывать перед тем как объект будет удален, а в деструкторе ничего делать не надо, не так ли?
lpd>Деструктор напрямую связан с объектом по логике. А вот объекты-обертки для освобождения ресурсов или для освобождения памяти — это хак.

Следовательно, все, кто использует RAII — хакеры.

А что-бы вы предпочли взамен RAII? Секцию кода, который выполняется при каждом выходе из функции? А как этот код получит доступ к переменным/состоянию внутренней части кода?

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, lpd, Вы писали:

lpd>>Деструктор напрямую связан с объектом по логике. А вот объекты-обертки для освобождения ресурсов или для освобождения памяти — это хак.

BFE>Следовательно, все, кто использует RAII — хакеры.

BFE>А что-бы вы предпочли взамен RAII? Секцию кода, который выполняется при каждом выходе из функции? А как этот код получит доступ к переменным/состоянию внутренней части кода?

Открывать ресурс в начале функции, а освобождать в конце этой же функции — это совсем лубок какой-то из маленьких программок-примеров. Вообще, файл — это абстракция ОС, управляемая по хэндлу, и не вижу смысла путать его с локальными переменными — абстракциями С++.
А динамическая память — это вообще не ресурс в этом смысле. Я не против умных указателей там, где действительно нужен подсчет ссылок, хотя чаще была бы полезней сборка мусора.
Ну и вообще можно сколько угодно оттачивать инструменты, но если строитель не умеет строить, то ничего не выйдет. Язык программирования и его фичи — это далеко не самое главное. Поэтому никакие фичи С++ не исправят плохую архитектуру программы, сколько этот язык не будут расширять.

Здравствуйте, lpd, Вы писали:

BFE>>А что-бы вы предпочли взамен RAII? Секцию кода, который выполняется при каждом выходе из функции? А как этот код получит доступ к переменным/состоянию внутренней части кода?

lpd>Открывать ресурс в начале функции, а освобождать в конце этой же функции — это совсем лубок какой-то из маленьких программок-примеров.
Нет. Это обычное дело для конфиг файлов.

lpd>Вообще, файл — это абстракция ОС, управляемая по хэндлу, и не вижу смысла путать его с локальными переменными — абстракциями С++.
А почему именно файл? А если речь про mutex, к примеру?

lpd>Ну и вообще можно сколько угодно оттачивать инструменты, но если строитель не умеет строить, то ничего не выйдет. Язык программирования и его фичи — это далеко не самое главное. Поэтому никакие фичи С++ не исправят плохую архитектуру программы, сколько этот язык не будут расширять.

Ну раз фичи языка не важны, значит с RAII в С++ всё нормально.

Здравствуйте, B0FEE664, Вы писали:

lpd>>Вообще, файл — это абстракция ОС, управляемая по хэндлу, и не вижу смысла путать его с локальными переменными — абстракциями С++.
BFE>А почему именно файл? А если речь про mutex, к примеру?

Файлы обычно первыми приводят в пример когда говорят о преимуществах RAII.
С lock_guard на мой взгляд нужно искать по коду где же этот мьютекс освободится, писать дополнительные блоки {}, поэтому проще явно написать unlock(). Да и с мьютексами обычно проблемы гораздо сложнее, чем просто забыть разлочить. Но это вопрос вкуса, не вижу большой разницы для мьютексов.

Здравствуйте, lpd, Вы писали:

lpd>С lock_guard на мой взгляд нужно искать по коду где же этот мьютекс освободится, писать дополнительные блоки {}, поэтому проще явно написать unlock().
Но ведь ровно наоборот, если у вас в коде есть явные unlock(), то придётся просматривать весь код в поисках не только unlock(), но и всех выходов из функции.

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

Ну не знаю. У меня с мьютексами вообще никаких проблем никогда не было, хотя все приложения за последние 15 лет — многопоточные. Если у вас проблемы с мьютексами, значит у вас в архитектуре что-то не правильно написано.

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, lpd, Вы писали:

BFE>Но ведь ровно наоборот, если у вас в коде есть явные unlock(), то придётся просматривать весь код в поисках не только unlock(), но и всех выходов из функции.
Ну не знаю, мне проще явно написать unlock(), чем искать где закрывается нужный блок. Но это вопрос вкуса, мне не принципиально.

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

BFE>Ну не знаю. У меня с мьютексами вообще никаких проблем никогда не было, хотя все приложения за последние 15 лет — многопоточные. Если у вас проблемы с мьютексами, значит у вас в архитектуре что-то не правильно написано.

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