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

O>Ну так возможность выстрелить себе в ногу — это не баг, а фича С++
O>Мне плюсы нравятся за эту свободу.

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

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

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

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

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

Здравствуйте, Евгений Музыченко, Вы писали:

_>>>Всё очень просто если C++ будет не совместим с C, то он потеряет интерфейс к внешнему миру и будет чуть более чем бесполезен.

A>>+100500

ЕМ>Вы точно поняли, о чем здесь речь?

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

Комментарий "+100500" относился ко всему блоку, а в первую очередь к "C++ на этой совместимости до сих пор паразитирует". Я видел крайне мало проектов, написанных на C++. Большинство написано на квазиязыке под названием "C/C++". И если бы от людей требовалось выбрать, C++ без C или C без C++, я бы на C++ не поставил.

A>>Особенно забавно, как надутые плюсовики со своим "фу, это не C++ way" даже не понимают, что пилят сук, на котором сидят.

ЕМ>Так это, по сути, не зрелые программисты, которые решают задачу наиболее подходящим набором имеющихся средств, а люди, не вышедшие из стадии ученичества, которые решают любую задачу "как учитель научил", "как старшие показали" и т.п.

Не думаю. Чистота это объективная ценность, и как раз зрелые программисты это понимают. При прочих равных, когда всё написано на одном языке, а не на смеси двух, это лучше. Консистентность, все дела. Только вот этих "прочих равных" нет.

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

A>Есть старое соглашение: если две строки кода написаны подряд, а комментарий — через вертикальный пробел, он относится ко всему блоку.

Если такое соглашение и есть, это лишь одно из множества разных соглашений, которые по факту являются соглашениями в относительно локальных группах. Ну и вряд ли стоит распространять стили кодирования формальных языков на естественные. Так недалеко до КГ/АМ, КД-ЧД и подобного.

A>Комментарий "+100500" относился ко всему блоку, а в первую очередь к "C++ на этой совместимости до сих пор паразитирует". Я видел крайне мало проектов, написанных на C++. Большинство написано на квазиязыке под названием "C/C++". И если бы от людей требовалось выбрать, C++ без C или C без C++, я бы на C++ не поставил.

Что именно Вы понимаете под "написанием на C++"? По моему опыту, под этим чаще всего понимают парадигму "все есть объект" (в которой даже для какого-нибудь поиска наибольшего значения в массиве непременно нужно оформить массив в виде объекта, который затем попросить найти), и непременное использование STL, Boost и подобных средств.

Если отбросить всю эту вкусовщину, то "программой, написанной на языке X", следует считать любую программу, использующую элементы языка X в соответствии с решаемой задачей. Иначе программу, которая вроде бы написана на C, но не использует адресной арифметики, составных операций присваивания, операции ?:, функций stpbrk и qsort, придется считать написанной на чем-то другом.

Поэтому, если отказаться, наконец, от вымученной части совместимости с C ("молчаливые" сужающие преобразования, столь же "молчаливая" обработка C-style cast, определение неинициализированных переменных без нужды и подобное), то сразу станет видно, на каком языке написана программа.

A>Чистота это объективная ценность, и как раз зрелые программисты это понимают. При прочих равных, когда всё написано на одном языке, а не на смеси двух, это лучше. Консистентность, все дела.

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

C++ заслуженно считается "мультипарадигмальным" языком, и многие уважаемые его апологеты не устают подчеркивать, что не нужно тащить в программу ООП, потоки ввода/вывода, шаблоны, стандартные контейнеры, исключения, безымянные функции и прочее лишь потому, что они есть в языке или STL. Если кто называет программу без всего этого "написанной не на C++", даже если для решения задачи этого на фиг не нужно, то он тупо не понимает сути C++, рассматривая его просто в качестве "еще одного ЯВУ".

Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>А разумный подход — каждую ситуацию, которая хоть сколько-нибудь регулярно создает проблемы, считать ошибкой, если в коде явно не указано, конкретно здесь (а не вообще везде по умолчанию) программист четко понимает, что делает (ну, или возомнил, будто понимает).
Вот это очень хреновый принцип. Он самое главное зло. В стандарте прописано что программа без ошибок не содержит UB, а если содержит то можно делать что угодно. И главное что это принцип не локален. Если UB где-то далеко, то оно может повлиять на код в котором не было UB, превратив его в не то было изначально. То есть применяются преобразования которые нарушают логику работы. Вместо того что бы предупреждать о ни откуда не следующих предположениях обрядах, компилятор молча делает гадости. Более того стандарт предписывает использовать модели данных ничего не имеющие общего с реальным железом. Например указатель помимо числа имеет еще кучу shadow свойств, значения 8битного байта кодирую 257 величин 0..255 и еще "poison". Что помогает компилятору делать изощренные подставы в самых неожиданных местах. А к этому еще следует добавить что большие программы не пишутся одним программистом, а толпой. То по определению будут UB которые компилятор обязательно не сегодня, так в будущем превратит в баги.

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

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

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

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

ЕМ>>А разумный подход — каждую ситуацию, которая хоть сколько-нибудь регулярно создает проблемы, считать ошибкой, если в коде явно не указано, конкретно здесь (а не вообще везде по умолчанию) программист четко понимает, что делает (ну, или возомнил, будто понимает).

_>Вот это принцип очень хреновый. Он самое главное зло.

Что именно Вы называете злом? Вы ж вроде как возражаете мне, а затем

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

Повторяете то же самое, за что выступаю и я.

_>по определению будут UB которые компилятор обязательно не сегодня, так в будущем превратит в баги.

Поэтому и нужны, с одной стороны, предупреждения компилятора на любую странность, которую он может усмотреть в коде, а с другой — языковые средства (в виде атрибутов, или хотя бы прагм), позволяющие объяснить компилятору, что программист имел в виду конкретно в этой конструкции, а не во всей программе/модуле/функции.

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

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

Это где такое? У меня последние версии VC++ прекрасно работают под семерками, на которые даже обновления не ставились много лет. Но за привычку тащить в программу новые модные фичи лишь потому, что они появились, надо нещадно гнобить, при возможности — наказывать. Как и за привычку тащить в программу новые модные фичи ОС, на сайт — новые модные фичи браузеров, и т.п.

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

А чем здесь поможет явная фаза синтеза кода? Есть же возможность получить у компилятора код после препроцессора (убогая, как и сам тот препроцессор) — разве кто-то использует полученный код иначе, как для просмотра с целью отладки?

Если же речь о том, чтобы видеть процесс и результат разворачивания шаблонов, то это безусловно нужно. Как и адекватные средства метапрограммирования, доступные из шаблонов (кто видел нормальные старые макропроцессоры, тот знает, о чем речь, а подавляющее большинство даже не представляет, что управлять порождением кода из шаблона вообще можно хоть как-то иначе, кроме как через имеющиеся в C++ кривые костыли). Нужны средства отладки шаблонов — хотя бы возможность вывода сообщений о фактических параметрах, истинности/ложности условий и прочем.

_>Сложность при этом перемножается как кода, так и требования к знаниям программиста, что приводит к слишком долгому обучению.

А в итоге приводит к тому, что изрядная часть этой сложности заметается под ковер в виде STL/Boost, устройство и работу которых полностью понимают, подозреваю, считанные проценты всех "плюсовиков", и которые остальным предлагается использовать "как есть", под эгидой "мы за тебя уже все придумали, и нех бухтеть, что оно выглядит ужасно — работает же!". А от неспособности за адекватное время понять, как устроен и работает используемый механизм, проистекает подход "на фига мне знать, как работают двигатель и трансмиссия — у меня есть две педали и селектор".

_>Чем хорош C — простотой. Чем плох C++ — туда наталкивают всякий мусор, не решив фундаментальных проблем, которые были заложены в самом начале.

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

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

_>Чем хорош C — простотой. Чем плох C++ — туда наталкивают всякий мусор, не решив фундаментальных проблем, которые были заложены в самом начале.
Вы когда говорите, что простой уточняйте там С89 или С K&R.

А то для меня С это современный С:

#include <stdio.h>
#include <time.h>

 const char message[] = {
#embed "message.txt" if_empty('M', 'i', 's', 's', 'i', 'n', 'g', '\n')
,'\0' // null terminator
};
 

typedef struct Rectangle_t{} Rectangle;
typedef struct Circle_t{} Circle;

void print_rectangle(Rectangle r[static 1]) {}
void print_circle(Circle c[static 1]) {}

#define PrintObj(x) \
 _Generic( (x), \
   Rectangle*: print_rectangle, \
   Circle*: print_circle) ( x )

constexpr int RealContantInC = 0;

char x(size_t n)
{
  char buf[n];
  buf[RealContantInC] = 'a';
  return buf[0];
}

int main() {

  Rectangle r = {};
  PrintObj(&r);

  int i = { 1 };

  double numbers[] = {0, [10]=55, 89, [5]=5, 8, [1]=1, 1, 1};

  struct tm * today = &(struct tm) {
   .tm_year = 123, .tm_mon = 3, .tm_mday = 20 };
  mktime(today);

  auto buffer = (char[42]){};
  strftime(buffer, 42, "%A %F", today);

  return 0;
}

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

_NN>А то для меня С это современный С:

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

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

Здравствуйте, Евгений Музыченко, Вы писали:

A>>Есть старое соглашение: если две строки кода написаны подряд, а комментарий — через вертикальный пробел, он относится ко всему блоку.

ЕМ>Если такое соглашение и есть, это лишь одно из множества разных соглашений, которые по факту являются соглашениями в относительно локальных группах. Ну и вряд ли стоит распространять стили кодирования формальных языков на естественные. Так недалеко до КГ/АМ, КД-ЧД и подобного.

Ты не поверишь...

https://rsdn.org/article/mag/200401/codestyle.XML#EIIAE

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

A>>Комментарий "+100500" относился ко всему блоку, а в первую очередь к "C++ на этой совместимости до сих пор паразитирует". Я видел крайне мало проектов, написанных на C++. Большинство написано на квазиязыке под названием "C/C++". И если бы от людей требовалось выбрать, C++ без C или C без C++, я бы на C++ не поставил.

ЕМ>Что именно Вы понимаете под "написанием на C++"? По моему опыту, под этим чаще всего понимают парадигму "все есть объект" (в которой даже для какого-нибудь поиска наибольшего значения в массиве непременно нужно оформить массив в виде объекта, который затем попросить найти), и непременное использование STL, Boost и подобных средств.

Простой пример. Я когда-то спрашивал

Автор: Alekzander
Дата: 17.06.23

, как написать в плюсах is in set.

В Си это делается при помощи пачки макросов IS_IN_SET2(), IS_IN_SET3() ... IS_IN_SETN(), связанных вариадическим макросом. Это ужасное решение, безусловно. Если написать такой код: https://stackoverflow.com/a/11763277/14400772, можно нечаянно вызвать Сатану. А если ещё заставить его работать в студийном компиляторе: https://stackoverflow.com/a/5134656/14400772, то можно разбудить Ктулху.

Но это РЕШЕНИЕ. А вот если сравнить его с самым лучшим предложенным плюсовым кодом (конечно же, на шаблонах), то. Начнём с того, что оно тоже очень корявое. Есть такое соглашение (среди создателей языков), что шаблоны это обобщения на типы, а не просто черезжопный интерфейс к препроцессору. Но плюсовики, как ты выше, делают удивлённые глаза: мы про такие соглашения ничего не слышали! Пусть это будет на их совести, но факт в том, что это, строго говоря, НЕ РЕШЕНИЕ. Очевидное условие — отсутствие паразитного call'а, потому что если ты на него согласен, хватит и простой перегрузки функций.

Мало того, что #define это по духу чисто сишный подход, так необходимая часть (__VA_ARGS__) ещё и не поддерживалась в плюсах аж 12 лет. При отсутствии альтернативы. Альтернативой был бы нормальный препроцессор, а не говно мамонта из языка Си. Вот поэтому и приходится смешивать старые и новые напластования: вариантов просто нет. Что, конечно, само по себе не очень хорошо.

А ты спрашиваешь, зачем в плюсы тянут совместимость с Си. Зачем в 11-ые плюсы, например, добавили вариадические макросы из Си99? По крайней мере, теперь можно хотя бы через сишные конструкции решить поставленную задачу. А кто не согласен, может показать сиплюсплюсное решение, с выполнением всех условий (отсутствием call'а в первую очередь).

ЕМ>Поэтому, если отказаться, наконец, от вымученной части совместимости с C ("молчаливые" сужающие преобразования, столь же "молчаливая" обработка C-style cast, определение неинициализированных переменных без нужды и подобное), то сразу станет видно, на каком языке написана программа.

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

Нахера мне нужен язык с ручным управлением памятью, если в нём кастинг и инициализация работают не как в Си?

Создатели плюсов поступили очень умно, решив, вот именно, ПАРАЗИТИРОВАТЬ на Си. Если бы они сделали всё то, что ты предлагаешь, у них бы получилось что-то типа D. То есть, дико популярное, но только в очень узких кругах.

Здравствуйте, Евгений Музыченко, Вы писали:

П>>Чтобы можно было итеративно улучшать сишное говно, потихоньку переделывая его на нормальном языке

ЕМ>Я же сказал, что вполне допускаю, что лет двадцать-тридцать назад кто-то еще это делал. За последние лет пятнадцать примеры есть?

Не знаю, как остальные, я сам так постоянно делаю

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

A>При отсутствии альтернативы. Альтернативой был бы нормальный препроцессор, а не говно мамонта из языка Си.

Я тут вычитал идею писать на связке PHP и C++. С каждым днём она кажется мне всё менее безумной.

Впрочем, наверно, вместо PHP можно взять и что-то получше, да? PHP же не позволяет развернуть #pragma once в гарды? Как там реализовать конструкцию "добавить в конец файла"?

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

A>Ты не поверишь...
A>https://rsdn.org/article/mag/200401/codestyle.XML#EIIAE

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

A>Простой пример. Я когда-то спрашивал

Автор: Alekzander
Дата: 17.06.23

, как написать в плюсах is in set.

Тут нужно начать с того, что задача именно в таком виде не является достаточно типовой, чтобы иметь в языке какие-то свойства именно под нее. А вот возможность определять наборы идентификаторов, по аналогии с перечислимым типом в Pascal, и делать из них множество, была бы весьма полезна. Тем более, что этот механизм естественным образом ложится на битовые операции (операции с множествами в Pascal компилируются в банальные or, and, test).

A>В Си это делается при помощи пачки макросов IS_IN_SET2(), IS_IN_SET3() ... IS_IN_SETN(), связанных вариадическим макросом. Это ужасное решение, безусловно.

Полностью согласен.

A>Но это РЕШЕНИЕ. А вот если сравнить его с самым лучшим предложенным плюсовым кодом (конечно же, на шаблонах), то. Начнём с того, что оно тоже очень корявое.

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

A>Есть такое соглашение (среди создателей языков), что шаблоны это обобщения на типы, а не просто черезжопный интерфейс к препроцессору.

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

A>Но плюсовики, как ты выше, делают удивлённые глаза: мы про такие соглашения ничего не слышали!

Вы меня точно ни с кем не путаете? Или каждого, кто выступает в поддержку C++ в любой его форме, автоматически записываете в ревнители "канонических плюсов", которые нынче преобладают?

A>Очевидное условие — отсутствие паразитного call'а, потому что если ты на него согласен, хватит и простой перегрузки функций.

inline не спасает?

A>Альтернативой был бы нормальный препроцессор, а не говно мамонта из языка Си.

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

A>Выше уже написали: попробуйте, если такие смелые. Посмотрим, сколько на нём программистов останется.

Ну вот Вы бы ушли с удобного в целом языка лишь потому, что его компилятор по умолчанию стал выдавать множество предупреждений (которые, если их внимательно прочитать, чаще всего спасают Вас от вероятных косяков, нежели просто надоедают из вредности), любое из которых, или даже все вместе, можно подавить пометками в тексте программы или ключами компилятора?

A>И так все поразбежались

Поразбежались в основном те, кто предпочитал использовать разумное подмножество C++ (как я, например), но руководство заставляет их переходить на "современный стиль", вызывающий рвотный рефлекс. Если человеку нужно просто решать задачи, и ему не диктуют в деталях правил их решения, что может согнать его с инструмента?

A>Нахера мне нужен язык с ручным управлением памятью, если в нём кастинг и инициализация работают не как в Си?

Вот сейчас вообще не понял. Какая между этим связь? Это ж совершенно ортогональные друг другу вещи.

A>Создатели плюсов поступили очень умно, решив, вот именно, ПАРАЗИТИРОВАТЬ на Си. Если бы они сделали всё то, что ты предлагаешь, у них бы получилось что-то типа D. То есть, дико популярное, но только в очень узких кругах.

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

Если так, то что они делают на C? Почему они не пишут на ассемблерах, или даже в машинном коде? Ведь и в C, и даже в ассемблерах, непременно есть какой-то контроль, который никак не обойти.

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

П>я сам так постоянно делаю

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

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

A>Есть такое соглашение (среди создателей языков), что шаблоны это обобщения на типы

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

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

A>Для is is set тоже нужно обобщение на типы. Но это второстепенная задача. Главное там — генерация произвольного количества сравнений.

Если элементов (идентификаторов) не больше, чем количество разрядов в машинном слове, то сравнения вообще не нужны. Нужно преобразовать проверяемое значение в битовую маску, и с помощью команды типа test проверить, входит ли она в множество, образованное совокупностью представленных элементов. Множество (битовая маска) вычисляется на этапе компиляции. Если проверяемое значение заведомо не может быть вне множества, то не нужны даже предварительные сравнения на больше/меньше.

Здравствуйте, Евгений Музыченко, Вы писали:

П>>я сам так постоянно делаю

ЕМ>И что, прямо-таки заломает в исходном "сишном говне" по-быстрому поправить самые костыльные места, чтоб избавиться от ошибок, а те, что порождают предупреждения, до поры пометить подавителями? Непременно нужно, чтоб то говно, притащенное в плюсовую программу, сразу компилировалось молча?

Если бегать по коду и адресно расставлять подавители — да, заломает. Пойду и глобально подавлю.

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

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

П>Если бегать по коду и адресно расставлять подавители — да, заломает. Пойду и глобально подавлю.

Именно так — "работает же! нечего там править!".

П>менять поведение языка в фундаментальных вещах, по ключикам из командной строки, или вообще, по опциям, расставленным в коде — это лютейшая дичь

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

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Тогда, во-первых, этот вот щенячий восторг "блин, программа писана полвека назад, а собралась без единой ошибки" будет хоть как-то разбавлен указаниями компилятора на то, что программа, вообще-то, писана на коленке и сплошь в костылях, и без ошибок собралась чисто случайно. Во-вторых, при беглом просмотре кода будет видно, насколько часто в нем применяются методы сгибания о колено.

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


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

Так сейчас всё так и есть, разве не так? Кроме идиотских пауз

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

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

А то я таких программ не видел. Чтоб убрать самые очевидные косяки, одним требуется несколько часов, другим достаточно 15-20 минут.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Поэтому и нужны, с одной стороны, предупреждения компилятора на любую странность, которую он может усмотреть в коде, а с другой — языковые средства (в виде атрибутов, или хотя бы прагм), позволяющие объяснить компилятору, что программист имел в виду конкретно в этой конструкции, а не во всей программе/модуле/функции.
Вообще-то надо более вменяемый язык, чтобы он не вызывал столько неоднозначностей и имел возможность явно указывать что можно оптимизатору додумывать, а что нет.

_>>Современная беда в другом, что бы собрать исходник, надо самый свежий компилятор, который внезапно работает только на самой распоследней сырой ос.
ЕМ>Это где такое?
В линухах

ЕМ>У меня последние версии VC++ прекрасно работают под семерками, на которые даже обновления не ставились много лет. Но за привычку тащить в программу новые модные фичи лишь потому, что они появились, надо нещадно гнобить, при возможности — наказывать. Как и за привычку тащить в программу новые модные фичи ОС, на сайт — новые модные фичи браузеров, и т.п.
VStudio 2023 не ставиться на семёрку. Компилятор по умолчанию генерит код который не семёрке может не работать. Браузеры 7ку тоже не поддерживают, даже питон и пхп не семёрке не пускаются.

_>>добавить в компилятор дополнительную фазу синтеза кода никому в голову не приходит. Вместо этого все ворчат на макросы и продолжают их использовать, добавляют к шаблонам концепты, вычисления времени компиляции рефлексию, короче всё месят в одну кучу.
ЕМ>А чем здесь поможет явная фаза синтеза кода? Есть же возможность получить у компилятора код после препроцессора (убогая, как и сам тот препроцессор) — разве кто-то использует полученный код иначе, как для просмотра с целью отладки?
Фаза синтеза кода нужна для выбора реализации в условиях заданных ограничений, подбора контейнеров и трансформации алгоритмов и т.п. без онанизма в виде шаблонных городух и будующей рефлексии.

ЕМ>Если же речь о том, чтобы видеть процесс и результат разворачивания шаблонов, то это безусловно нужно. Как и адекватные средства метапрограммирования, доступные из шаблонов (кто видел нормальные старые макропроцессоры, тот знает, о чем речь, а подавляющее большинство даже не представляет, что управлять порождением кода из шаблона вообще можно хоть как-то иначе, кроме как через имеющиеся в C++ кривые костыли). Нужны средства отладки шаблонов — хотя бы возможность вывода сообщений о фактических параметрах, истинности/ложности условий и прочем.
Не нужно всё это, если есть фаза синтеза кода. Это следствие того что на макросы забили и решили их не развивать, но выкинуть не могут ибо без них никак.

_>>Сложность при этом перемножается как кода, так и требования к знаниям программиста, что приводит к слишком долгому обучению.
ЕМ>А в итоге приводит к тому, что изрядная часть этой сложности заметается под ковер в виде STL/Boost, устройство и работу которых полностью понимают, подозреваю, считанные проценты всех "плюсовиков", и которые остальным предлагается использовать "как есть", под эгидой "мы за тебя уже все придумали, и нех бухтеть, что оно выглядит ужасно — работает же!". А от неспособности за адекватное время понять, как устроен и работает используемый механизм, проистекает подход "на фига мне знать, как работают двигатель и трансмиссия — у меня есть две педали и селектор".
Нет это приводит к тому что под капотом этих библиотек страх и ужас.

_>>Чем хорош C — простотой. Чем плох C++ — туда наталкивают всякий мусор, не решив фундаментальных проблем, которые были заложены в самом начале.
ЕМ>Именно. Хотя, при более грамотном подходе, C++ мог быть не намного сложнее C, и при этом иметь все те возможности, которые имеет сейчас, и даже бОльшие.
Нет при правильном подходе C++ был изначально просто сменной надстройкой над C. И вообще-то никто не мешает использовать разные надстройки.

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


A>>При отсутствии альтернативы. Альтернативой был бы нормальный препроцессор, а не говно мамонта из языка Си.

A>Я тут вычитал идею писать на связке PHP и C++. С каждым днём она кажется мне всё менее безумной.
A>Впрочем, наверно, вместо PHP можно взять и что-то получше, да? PHP же не позволяет развернуть #pragma once в гарды? Как там реализовать конструкцию "добавить в конец файла"?

Еще вариант lua + c