C vs C++ , Не опять а снова

Цитата Flex Ferrum @ 15.03.18, 08:29

Ээээ... А тут точно про C++ vs C?

Иди-иди в свой свиттер!

Цитата Qraizer @ 14.03.18, 15:06

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

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

Цитата

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

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

Цитата

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

Во-первых, это голословное обвинение. Баги такие находят как в системах на Си, так и в системах на С++ Потому что дело в людях, а не в языке(в данном случае).
Во-вторых, есть инструменты для поиска этих самых утечек, как и других проблем. От статических анализаторов до средств времени исполнения.

Цитата

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

У сишником так же вполне себе может не быть таких проблем

Цитата

Цитата D_KEY @ 14.03.18, 05:48

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

Тебе который раз, третий?, указать, что выбор никто не осуждает?

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

Добавлено 15.03.18, 09:03

Цитата Qraizer @ 14.03.18, 15:06

D_KEY, а почему должно смущать сознательное использование фичи, сознательное введённое в язык?

Знаешь, не стоит забывать про такую штуку, как здравый смысл
Так вот, подобные "фичи" с точки зрения этого самого здравого смысла, вызывают лишь недоумение. Причем даже у C++ разработчиков.
Да, все можно объяснить, порывшись в стандарте и т.п. Но это ведь только ухудшает ситуацию с языком, если подумать.

Добавлено 15.03.18, 09:11

Цитата Саттер

widget w;                   // (a)

This code declares a variable named w, of type widget. For most types, it is initialized using the default constructor widget::widget().

Note that w is not initialized and contains garbage values if widget happens to be a built-in type like int, or a simple “int-like” class type with what’s called a “trivial” default constructor—a type that relies on the compiler-generated default constructor, has no virtual functions or virtual base classes or data member initializers, and all its bases and members satisfy the same restrictions.

...

widget w();                 // (b)

This is a pre-modern C++ pitfall: At first glance, it may look like just another variable declaration calling a default constructor widget::widget(); in reality, thanks to a grammar ambiguity, it’s a function declaration for a function named w that takes no parameters and returns a widget object by value.

...

Rather, C++11 solves this by providing a syntax that supersedes case (b) in nearly all cases, so that we don’t need to ever fall into this pit anymore:
© is non-vexing and clear.

widget w{};                 // (c)

Here we have the first reason to prefer { } to ( ): For any class type widget, line © does the “best parts” of (a) and (b)—it always initializes the variable, and is never ambiguous with a function declaration. No vex, no fuss, no muss.

... this really is just as simple as it looks ...

Да-да.

А потом начинается...

Добавлено 15.03.18, 09:19

struct A {
  A() { std::cout << "A::A()" << std::endl; }
};
 
A a{}; // ok

Выведет A::A()

Теперь удаляем:

struct A {
  A() = delete;
};
 
A a{}; // ok

А если добавить еще конструктор?

struct A {
  A() = delete;
  A(int) {}
};
 
A a{}; // fail

Ой

А если так:

struct A {
  explicit A() = delete;
};
 
A a{}; // fail

А так:

struct Base {};
 
struct A : Base {
  A() = delete;
};
 
A a{}; // fail

Добавлено 15.03.18, 09:24
Так вот некоторые люди предпочитают не задрачиваться на "особенности" языка, не талмуды по языку бесконечно читать, а решать конкретные разработчиские задачи, которые перед ними стоят. И многим людям(сам я к ним не отношусь, надо заметить) проще взять обычный Си и решить на нем задачу, чем постоянно насиловать себе мозг проблемами языка(на их взгляд).

Сообщение отредактировано: D_KEY - 15.03.18, 09:25

Цитата D_KEY @ 15.03.18, 08:55

Так вот некоторые люди предпочитают не задрачиваться на "особенности" языка, не талмуды по языку бесконечно читать, а решать конкретные разработчиские задачи,

Давай будем честными: на такие вот особенности языка ты имеешь довольно небольшие шансы напороться. Но вот, скажем, довольно простая задачка: реализовать программируемый калькулятор с регистровой памятью и вычислениями в обратной польской нотации (на стеке). Коорче, старый добрый МК-61/МК-52. Как её реализация будет выглядеть на С? На С++14 (чистом, без сторонних библиотек) - вот так. Довольно компактно.

Цитата JoeUser @ 15.03.18, 00:04

Вот как-то я писал код на Перл 5 для теста многопоточной записи в БД PostgreSQL.

ммм. я б постыдился такой код показывать

Скрытый текст

Цитата negram @ 15.03.18, 09:43

ммм. я б постыдился такой код показывать

Он делает ровно то, что должен делать. И ничего лишнего. Но стыдиться или нет - дело твое.

Цитата Flex Ferrum @ 15.03.18, 09:35

Давай будем честными: на такие вот особенности языка ты имеешь довольно небольшие шансы напороться.

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

Цитата JoeUser @ 15.03.18, 10:29

Он делает ровно то, что должен делать. И ничего лишнего

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

Цитата Flex Ferrum @ 15.03.18, 09:35

Но вот, скажем, довольно простая задачка: реализовать программируемый калькулятор с регистровой памятью и вычислениями в обратной польской нотации (на стеке). Коорче, старый добрый МК-61/МК-52. Как её реализация будет выглядеть на С? На С++14 (чистом, без сторонних библиотек) - вот так. Довольно компактно.

D_KEY, ну так как?

Цитата Flex Ferrum @ 15.03.18, 12:14

Цитата Flex Ferrum @ 15.03.18, 09:35

Но вот, скажем, довольно простая задачка: реализовать программируемый калькулятор с регистровой памятью и вычислениями в обратной польской нотации (на стеке). Коорче, старый добрый МК-61/МК-52. Как её реализация будет выглядеть на С? На С++14 (чистом, без сторонних библиотек) - вот так. Довольно компактно.

D_KEY, ну так как?

Я что, по-твоему, пишу на Си?

Добавлено 15.03.18, 12:22
Описание-то есть? Какие конкретно операции и т.п.

Цитата D_KEY @ 15.03.18, 12:21

Описание-то есть? Какие конкретно операции и т.п.

Так имплементация же есть (по ссылке). На плюсах, правда.

Цитата D_KEY @ 15.03.18, 08:43

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

D_KEY, там была аргументация, почему именно так, причём условная. Ты сознательно скипнул условие, написав при этом то же самое, и считаешь это спором?

Цитата D_KEY @ 15.03.18, 08:43

Когда ты пишешь нечто того же nginx, у тебя нет никакого представления о том, кто, как и где тебя будет запускать Выдвигать слишком сильные требования к окружению в данном случае бессмысленно.
...
Они тебя должны волновать с точки зрения информации. Хотя бы залогировать это дело тебе во многих случаях нужно.

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

Цитата D_KEY @ 15.03.18, 08:43

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

Это не вопрос протокола, это вопрос его реализации в коде. Программист тем и отличается от кодера, что творчески подходит к своему ремеслу.

Цитата D_KEY @ 15.03.18, 08:55

Да при чем тут язык? Если программист напишит кривой код, тебя никакой автоматический вызов деструктора не спасет.
...
Тут спорить не с чем. Кроме того, что не в языке дело. ...

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

Цитата D_KEY @ 15.03.18, 08:55

У сишником так же вполне себе может не быть таких проблем

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

Цитата D_KEY @ 15.03.18, 08:55

Знаешь, не стоит забывать про такую штуку, как здравый смысл
...

Здорово. И что? Ты же не ответил.

Добавлено 15.03.18, 13:54
Т.к. и примеров ты привёл много вместо одного, соответственно я могу и вопросов позадать поболе. Почему вообще был deleteчен единственный конструктор, почему этот код сравнивается с кодом, где этот конструктор не единственный итп. В любом случае основной посыл остаётся в силе: зачем приводить в пример код, который написан сознательно для демонстрации сознательно введённых в язык фич? Ответив на все "зачем", ты и сам сможешь прийти к выводу, что все эти примеры демонстрируют только одно: случайно напороться на несоответствия маловероятно, зато ты имеешь возможность написать такой код сознательно, если вдруг приспичит.

Сообщение отредактировано: Qraizer - 15.03.18, 14:04

Цитата Qraizer @ 15.03.18, 13:41

Может и не быть, но не застрахован же.

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

Потому что, как я и не только я выше писали, дело не только в языке, но и в программерах. Не "программисты застрахованы", а язык предлагает им для этого средства. И не "писатели ... не застрахованы", а все баги выловлены.
Другой вопрос: стоимость достигнутого. Я пользуюсь предлагаемыми средствами Плюсов, они же выловили все Сишные баги. Кто-то другой не пользуется и тем самым нивелирует своё потенциальное преимущество, кто-то другой из них пока ещё не всё отладил.

Цитата Астарот @ 15.03.18, 13:57

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

А потом, хоп-на-на-най, heartbleed.

Цитата Flex Ferrum @ 15.03.18, 12:29

Цитата D_KEY @ 15.03.18, 12:21

Описание-то есть? Какие конкретно операции и т.п.

Так имплементация же есть (по ссылке). На плюсах, правда.

Ну по имплементации не очень удобно восстанавливать исходную задачу
Тем более, что код может и компактный, но мне не нравится=)

Добавлено 15.03.18, 22:02
Особенно прекрасен макрос VISIT_COMMAND(ID)

Добавлено 15.03.18, 22:07
Qraizer, тяжеловато На основное отвечу завтра.

Добавлено 15.03.18, 22:10

Цитата Qraizer @ 15.03.18, 14:03

Я пользуюсь предлагаемыми средствами Плюсов, они же выловили все Сишные баги. Кто-то другой не пользуется и тем самым нивелирует своё потенциальное преимущество, кто-то другой из них пока ещё не всё отладил.

Во. Согласен