Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Обратил внимание, что даже в последних стандартах подчеркивается, что ряд особенностей C++ (хотя бы пресловутое сужение типа) существует лишь для совместимости с C.
C++ на этой совместимости до сих пор паразитирует
ЕМ>Насколько это востребовано вообще? Ладно, где-нибудь в начале-середине 90-х, когда в C++ устоялись еще не все базовые свойства, и многие банально опасались переходить с C, не зная, куда оно в итоге повернется. Но уже где-то к концу 90-х основные вещи устаканились и, если в последующие лет десять кто-то не переписал свой софт на C++, то уже вряд ли стал это делать позднее. Или до сих пор переписывают в товарных количествах?
ЕМ>В чем может быть ценность этой совместимости, кроме поощрения ленивых и малограмотных? Может, я чего не понимаю?
Всё очень просто если C++ будет не совместим с C, то он потеряет интерфейс к внешнему миру и будет чуть более чем бесполезен.
Подключение динамических библиотек C++ к чему-то еще очень весёлое занятие.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Обратил внимание, что даже в последних стандартах подчеркивается, что ряд особенностей C++ (хотя бы пресловутое сужение типа) существует лишь для совместимости с C.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Тогда уж критикуйте и тех, кто предлагал switch.
switch невозможен для повторяющихся значений констант и для объектов.
Кстати, есть ещё вариант C++23:
constexpr auto arrErrs = std::array{EAGAIN, EWOULDBLOCK, EINTR, ENOSPC, ENOBUFS, ENOMEM};
if ( std::ranges::contains(arrErrs, errno) )
...
или
if (const auto arrErrs = {EAGAIN, EWOULDBLOCK, EINTR, ENOSPC, ENOBUFS, ENOMEM}; std::ranges::contains(arrErrs, errno) )
...
Впрочем я ещё не перешёл на C++20, так что возможны, наверно, ещё варианты...
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Обратил внимание, что даже в последних стандартах подчеркивается, что ряд особенностей C++ (хотя бы пресловутое сужение типа) существует лишь для совместимости с C.
Дык, эта. Куча плюсового кода написана с учетом этих правил, и если их поменять, сломается пол мира. И никто старый код переписывать не будет только для того, чтобы он соответствовал новым стандартам. А если в новый стандарт протащат отказ от этой совместимости, то уверен, кто-нибудь да не поскупиться и закажет их.
А так — где можно — отказываются. register выкинули, auto полностью смысл поменяло
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Дык, если это делать, то делать грамотно. Ввести в язык способ явного объявления уровней совместимости, чтоб можно было описать их прямо в тексте, а не россыпью ключей компилятора или прагм, которые у всех разные. По умолчанию включать максимально строгий контроль, и нехай каждый, кому это не нравится, явно пишет в тексте "я умнее компилятора, я сам буду все контролировать, не пропущу ни одной мелочи". У тех, кто понимает толк, это довольно быстро станет стандартом де-факто, а на тех, кто ставит либеральные режимы, будут смотреть так же, как сейчас смотрят на любителей C-style cast или передачи объектов через void *.
Ты потом первый прибежишь с криками: "что за очередную #$%нину в плюсики вкорячили?"
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Про совместимость по ABI я вообще не говорю — без нее как раз нельзя. Я исключительно про совместимость с C по тексту программы.
Как ты из плюсового текста позовешь сишнию функцию. Например, системных вызов?
Тут вроде как только два пути: или c++ в каком-то виде понимает си, или FFI (Foreign Function Interface), как делается в языках, слишком уж не похожих на Си.
Здравствуйте, _NN_, Вы писали:
_NN>А то для меня С это современный С:
Он и есть современный, ибо активно тащит плюшки из других языков, в том числе из C++, но при этом изо всех сил подчеркивает, что "это труЪ C, а не какие-то ваши плюсы".
По-моему, давно пора забить на это противопоставление, и объединить языки в один. Ежели кому надо сделать свой компилятор, и влом реализовывать полный стандарт плюсов, то можно ограничиться разумным подмножеством — например, без шаблонов, исключений, безымянных функций, сопрограмм и еще чего-нибудь.
Здравствуйте, Евгений Музыченко, Вы писали:
П>>Чтобы можно было итеративно улучшать сишное говно, потихоньку переделывая его на нормальном языке
ЕМ>Я же сказал, что вполне допускаю, что лет двадцать-тридцать назад кто-то еще это делал. За последние лет пятнадцать примеры есть?
Здравствуйте, Евгений Музыченко, Вы писали:
П>>я сам так постоянно делаю
ЕМ>И что, прямо-таки заломает в исходном "сишном говне" по-быстрому поправить самые костыльные места, чтоб избавиться от ошибок, а те, что порождают предупреждения, до поры пометить подавителями? Непременно нужно, чтоб то говно, притащенное в плюсовую программу, сразу компилировалось молча?
Если бегать по коду и адресно расставлять подавители — да, заломает. Пойду и глобально подавлю.
Но вообще, менять поведение языка в фундаментальных вещах, по ключикам из командной строки, или вообще, по опциям, расставленным в коде — это лютейшая дичь
Обратил внимание, что даже в последних стандартах подчеркивается, что ряд особенностей C++ (хотя бы пресловутое сужение типа) существует лишь для совместимости с C.
Насколько это востребовано вообще? Ладно, где-нибудь в начале-середине 90-х, когда в C++ устоялись еще не все базовые свойства, и многие банально опасались переходить с C, не зная, куда оно в итоге повернется. Но уже где-то к концу 90-х основные вещи устаканились и, если в последующие лет десять кто-то не переписал свой софт на C++, то уже вряд ли стал это делать позднее. Или до сих пор переписывают в товарных количествах?
С другой стороны, я еще с конца 90-х привык для каждого нового проекта (в том числе переносимого с C) включать все возможные предупреждения, отключая явно лишь наиболее очевидные. Понятно, что на сишных текстах такой режим выдавал сотни-тысячи предупреждений, и какое-то время уходило на правку, зато все остальное время можно было не опасаться где-то незаметно накосячить. В этом смысле даже базовый (без дополнительного анализа со стороны компилятора) контроль типов в C++ гораздо правильнее либерального сишного.
В чем может быть ценность этой совместимости, кроме поощрения ленивых и малограмотных? Может, я чего не понимаю?
P.S. Речь исключительно о совместимости по синтакису/семантике кода. К связыванию и ABI вопрос не относился.
Здравствуйте, пффф, Вы писали:
П>Куча плюсового кода написана с учетом этих правил, и если их поменять, сломается пол мира. И никто старый код переписывать не будет только для того, чтобы он соответствовал новым стандартам. А если в новый стандарт протащат отказ от этой совместимости, то уверен, кто-нибудь да не поскупиться и закажет их.
Дык, если это делать, то делать грамотно. Ввести в язык способ явного объявления уровней совместимости, чтоб можно было описать их прямо в тексте, а не россыпью ключей компилятора или прагм, которые у всех разные. По умолчанию включать максимально строгий контроль, и нехай каждый, кому это не нравится, явно пишет в тексте "я умнее компилятора, я сам буду все контролировать, не пропущу ни одной мелочи". У тех, кто понимает толк, это довольно быстро станет стандартом де-факто, а на тех, кто ставит либеральные режимы, будут смотреть так же, как сейчас смотрят на любителей C-style cast или передачи объектов через void *.
Здравствуйте, Евгений Музыченко, Вы писали:
_>>если C++ будет не совместим с C, то он потеряет интерфейс к внешнему миру
ЕМ>Про совместимость по ABI я вообще не говорю — без нее как раз нельзя. Я исключительно про совместимость с C по тексту программы.
Чтобы можно было итеративно улучшать сишное говно, потихоньку переделывая его на нормальном языке, а не выкидывать сразу всё старое в мусорку и не писать заново на другом языке
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>По умолчанию включать максимально строгий контроль, и нехай каждый, кому это не нравится, явно пишет в тексте "я умнее компилятора, я сам буду все контролировать, не пропущу ни одной мелочи".
Да, это сразу гемор. Надо какое-то старьё собрать — будут глобально ставить самый совместимый уровень. Да и вообще, режим максимальной совместимости просто будут сразу по умолчанию ставить.
Иначе будет похоже на вечную борьбу с боромиром чекеров в рже
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В чем может быть ценность этой совместимости, кроме поощрения ленивых и малограмотных? Может, я чего не понимаю?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Обратил внимание, что даже в последних стандартах подчеркивается, что ряд особенностей C++ (хотя бы пресловутое сужение типа) существует лишь для совместимости с C. Может, я чего не понимаю?
Дает возможность сишникам использовать фичи С++, но писать в своем стиле.
Вообще, плюс плюсов в том, что можно плюсовать в любом нравящимся разработчику или его организации стиле, будь то си с классами, или метопрограммирование на шаблонах.
Вкратце, философию С++ можно охарактеризовать крылатой фразой
Здравствуйте, пффф, Вы писали:
П>Надо какое-то старьё собрать — будут глобально ставить самый совместимый уровень.
Вот и нехай ставят каждый раз явно. Вроде того, как иные водятлы вставляют затычку в замок ремня безопасности, и пассажирам сразу видно, как данный индивид относится, в том числе, к их безопасности.
Здравствуйте, Pzz, Вы писали:
Pzz>Как ты из плюсового текста позовешь сишнию функцию.
Объявлю ее, как extern "C". Это повлияет только на ABI, и никак не повлияет на правила вычисления фактических параметров, преобразования значения результата и прочее.
Здравствуйте, opfor, Вы писали:
O>Дает возможность сишникам использовать фичи С++, но писать в своем стиле. O>Вообще, плюс плюсов в том, что можно плюсовать в любом нравящимся разработчику или его организации стиле, будь то си с классами, или метопрограммирование на шаблонах.
Вы таки путаете понятие стиля программирования с использованием неявных (и неочевидных) свойств C, единственная выгода от которых — некоторое сокращение текста. Но реальную экономию времени это дает где-нибудь единицам из тысяч, у кого "весь текст программы в голове вместе с машинным кодом", а остальные благополучно потеряют "сэкономленное" время на отладке и поиске непонятных глюков, и вдобавок потратят дополнительное.
Здравствуйте, kov_serg, Вы писали:
_>C++ на этой совместимости до сих пор паразитирует _>Всё очень просто если C++ будет не совместим с C, то он потеряет интерфейс к внешнему миру и будет чуть более чем бесполезен.
+100500
Особенно забавно, как надутые плюсовики со своим "фу, это не C++ way" даже не понимают, что пилят сук, на котором сидят.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вы таки путаете понятие стиля программирования с использованием неявных (и неочевидных) свойств C, единственная выгода от которых — некоторое сокращение текста. Но реальную экономию времени это дает где-нибудь единицам из тысяч, у кого "весь текст программы в голове вместе с машинным кодом", а остальные благополучно потеряют "сэкономленное" время на отладке и поиске непонятных глюков, и вдобавок потратят дополнительное.
Ну так возможность выстрелить себе в ногу — это не баг, а фича С++
Мне плюсы нравятся за эту свободу.
Здравствуйте, Alekzander, Вы писали:
_>>Всё очень просто если C++ будет не совместим с C, то он потеряет интерфейс к внешнему миру и будет чуть более чем бесполезен.
A>+100500
Вы точно поняли, о чем здесь речь?
A>Особенно забавно, как надутые плюсовики со своим "фу, это не C++ way" даже не понимают, что пилят сук, на котором сидят.
Так это, по сути, не зрелые программисты, которые решают задачу наиболее подходящим набором имеющихся средств, а люди, не вышедшие из стадии ученичества, которые решают любую задачу "как учитель научил", "как старшие показали" и т.п.
Здравствуйте, 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.
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Есть старое соглашение: если две строки кода написаны подряд, а комментарий — через вертикальный пробел, он относится ко всему блоку.
ЕМ>Если такое соглашение и есть, это лишь одно из множества разных соглашений, которые по факту являются соглашениями в относительно локальных группах. Ну и вряд ли стоит распространять стили кодирования формальных языков на естественные. Так недалеко до КГ/АМ, КД-ЧД и подобного.
Соглашения по оформлению кода команды RSDN
...
Между группой комментариев и собственно кодом поставьте пустую строку. Это покажет, что комментарий относится к блоку кода, а не к конкретной инструкции. Напротив, если комментарий относится к конкретной инструкции, прижмите его вплотную к этой инструкции.
A>>Комментарий "+100500" относился ко всему блоку, а в первую очередь к "C++ на этой совместимости до сих пор паразитирует". Я видел крайне мало проектов, написанных на C++. Большинство написано на квазиязыке под названием "C/C++". И если бы от людей требовалось выбрать, C++ без C или C без C++, я бы на C++ не поставил.
ЕМ>Что именно Вы понимаете под "написанием на C++"? По моему опыту, под этим чаще всего понимают парадигму "все есть объект" (в которой даже для какого-нибудь поиска наибольшего значения в массиве непременно нужно оформить массив в виде объекта, который затем попросить найти), и непременное использование STL, Boost и подобных средств.
В Си это делается при помощи пачки макросов 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 в гарды? Как там реализовать конструкцию "добавить в конец файла"?
Охотно верю — это и есть соглашение внутри локальной группы. Те, кто в ней не участвует (например, я), не обязаны ничего об этом знать.
A>Простой пример. Я когда-то спрашивал
Тут нужно начать с того, что задача именно в таком виде не является достаточно типовой, чтобы иметь в языке какие-то свойства именно под нее. А вот возможность определять наборы идентификаторов, по аналогии с перечислимым типом в 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. И вообще-то никто не мешает использовать разные надстройки.
A>>При отсутствии альтернативы. Альтернативой был бы нормальный препроцессор, а не говно мамонта из языка Си.
A>Я тут вычитал идею писать на связке PHP и C++. С каждым днём она кажется мне всё менее безумной. A>Впрочем, наверно, вместо PHP можно взять и что-то получше, да? PHP же не позволяет развернуть #pragma once в гарды? Как там реализовать конструкцию "добавить в конец файла"?
Здравствуйте, kov_serg, Вы писали:
A>>Я тут вычитал идею писать на связке PHP и C++. С каждым днём она кажется мне всё менее безумной. A>>Впрочем, наверно, вместо PHP можно взять и что-то получше, да? PHP же не позволяет развернуть #pragma once в гарды? Как там реализовать конструкцию "добавить в конец файла"?
_>Еще вариант lua + c
Я не сталкивался с Lua, но он же вроде для ембеддинга, а не для препроцессинга?
Идея в том, чтобы писать макросы типа is_in_set на внешнем языке (типа PHP), пропускать через процессор (например, через pre build steps), он их будет разворачивать в нужное количество сравнений, а затем результат подавать на вход компилятору.
Только вот не уверен я, что код будет выразительнее, чем с дефайнами.
Кроме того, если мы захотим генерировать заголовочные прагма-гарды (#ifndef #define ... #endif) вместе с #pragma once или ИЗ #pragma once, вроде бы, похапе так не может, для этого надо уметь добавлять в конец, даже если там нет тега <? >, да ещё и по-умному, чтобы не было пересечений. Это не самая практичная задача, а просто пример того, что язык и его процессор должны уметь делать.
Здравствуйте, Евгений Музыченко, Вы писали:
_>>если C++ будет не совместим с C, то он потеряет интерфейс к внешнему миру
ЕМ>Про совместимость по ABI я вообще не говорю — без нее как раз нельзя. Я исключительно про совместимость с C по тексту программы.
Ну вот я пишу сейчас прошивку для микроконтроллера nRF. У них SDK на C. Примеры на C. В принципе я и пишу на C, но в целом почему бы мне не писать на C++, если очень хочется. Думаю, многие пишут. При этом у них в хедерах и inline функций хватает, и макросы вовсю используются. Тут текст от заголовка уже так просто и не отличить.
Здравствуйте, kov_serg, Вы писали:
_>Вообще-то надо более вменяемый язык, чтобы он не вызывал столько неоднозначностей и имел возможность явно указывать что можно оптимизатору додумывать, а что нет.
Язык-то зачем? По-моему, в плюсах в целом и синтаксис, и семантика вполне человеческие, за исключением отдельных крайних случаев, которые, при желании, можно постепенно выправить. Вполне достаточно поверху навесить — где атрибуты, где прагмы, а где можно и конструкции вроде паскалевских "управляющих комментариев".
_>>>что бы собрать исходник, надо самый свежий компилятор ЕМ>>Это где такое? _>В линухах
Ну, тамошняя мода непременно таскать все в исходниках, и собирать по месту, вообще крайне странна, если не сказать сильнее.
_>VStudio 2023
Имеете в виду 2022?
_>не ставиться на семёрку.
Да и хрен бы с ней. В студиях навороченные отладчики — скорее всего, там что-то завязано на свежие десятки. Имеет право.
Компиляторы, линкеры и прочие build tools из 2022 отлично работают под семеркой. Подозреваю, что будут работать даже под 2k, если версию в PE поправить. Чего б им не работать, коли это, по большому счету, командно-строковые преобразователи файлов.
_>Компилятор по умолчанию генерит код который не семёрке может не работать.
Компилятор никогда не генерил системно-зависимого кода. Все системные зависимости — в стандартных библиотеках. Самым свежим компилятором/линкером от VC++ можно делать EXE/DLL хоть под Win95, только версию в PE придется править, линкер не дает поставить subsystem меньше 5.0.
_>Браузеры 7ку тоже не поддерживают, даже питон и пхп не семёрке не пускаются.
УМВР ЧЯДНТ?
_>Фаза синтеза кода нужна для выбора реализации в условиях заданных ограничений, подбора контейнеров и трансформации алгоритмов и т.п. без онанизма в виде шаблонных городух и будующей рефлексии.
Зачем для этого нужна непременно фаза синтеза? Что мешает ввести любые адекватные конструкции для управления имеющимся механизмом? И рефлексию так же. Например, рассматривать каждую сущность (значение, тип, объект, функцию, параметр шаблона, сам шаблон и т.п.) как псевдообъект с набором свойств. Что-нибудь вроде __props(f).name — имя функции, __props(T).type — тип параметра T, и так далее. В любом мало-мальски удобном виде, лишь бы было.
_>Это следствие того что на макросы забили и решили их не развивать, но выкинуть не могут ибо без них никак.
Нет никакого смысла развивать макросы, которые обрабатываются, как тупые текстовые фрагменты. При таком подходе даже простые решения быстро упираются в невозможность генерации кода иначе, как простой текстовой подстановкой.
_>Нет это приводит к тому что под капотом этих библиотек страх и ужас.
Я именно так и выразился, почему нет-то?
_>Нет при правильном подходе C++ был изначально просто сменной надстройкой над C. И вообще-то никто не мешает использовать разные надстройки.
Я в упор не понимаю, для чего ему быть "надстройкой". Когда Win95 была "надстройкой" над досом, это хоть кому-то нравилось?
Здравствуйте, Alekzander, Вы писали:
A>Идея в том, чтобы писать макросы типа is_in_set на внешнем языке (типа PHP), пропускать через процессор (например, через pre build steps), он их будет разворачивать в нужное количество сравнений, а затем результат подавать на вход компилятору.
Ну сделаете Вы так, а дальше-то что? Задача ж сугубо частная, не так уж много задач можно решить таким образом, чтоб вся эта возня окупилась. Если уж делать механизм, то более-менее универсальный.
A>Это не самая практичная задача, а просто пример того, что язык и его процессор должны уметь делать.
В том-то и дело, что подобные решения всегда будут лишь частными. Чтоб можно было делать удобные и эффективные решения для разных задач, язык должен, с одной стороны, позволять извлекать из компилятора информацию о компилируемой программе, а с другой стороны — применять эту информацию для порождения других элементов программы.
Здравствуйте, vsb, Вы писали:
vsb>При этом у них в хедерах и inline функций хватает, и макросы вовсю используются. Тут текст от заголовка уже так просто и не отличить.
Так я и говорю, что подобные фрагменты можно было бы явно отмечать режимом совместимости, а не держать этот режим для всего по умолчанию.
, как написать в плюсах is in set.
ЕМ>Тут нужно начать с того, что задача именно в таком виде не является достаточно типовой, чтобы иметь в языке какие-то свойства именно под нее.
Во-первых.
Я привёл пример на тему, когда пишущий на C++ прибегает ко встроенному Си, и почему. Эти примеры я могу приводить и дальше, а этот выбрал потому, что он рядом, в этом же форуме, его все видели, и настоящие эксперты (не то, что я) привели какие-то решения, высоко оценённые другими экспертами.
Во-вторых.
Этот пример достаточно типовой, чтобы его привёл автор исходной статьи, тот который из PVS. То есть, это вообще не мой пример. Мой вклад тут в том, что я переформулировал задачу исходя из интересов программиста, а не компании PVS.
Маленький оффтопик. Я тут читал статью про лечение ВИЧ. Есть несколько случае полного излечения, когда следов вируса не обнаруживается много лет. Но медицина в эту сторону не копает. Знаешь, почему? Официальный ответ: это не нужно. Пока ты принимаешь антиретровирусную терапию, ты будешь здоров (не разовьётся СПИД, не сократится жизнь и т.д.). То есть, ты здоров, пока работаешь кошельком для фармацевтов. Удобно, да? Врачи не очень заинтересованы в том, чтобы люди были здоровы. Они заинтересованы в том, чтобы люди лечились.
Вот и авторам статических анализаторов не нужно, чтобы ты писал здоровый код. Ведь тогда анализаторы перестанут находить у тебя ошибки, а ты перестанешь их покупать. Поэтому, увидев совет пользоваться форматированием (которое особо не спасает), я переформулировал эту задачу так: в каком виде надо записывать такие сравнения, чтобы эта ошибка стала невозможной? Как выработать здоровую привычку для здорового кода? Такую, как Йода-сравнения, например. Вот и всё. А сама ошибка достаточно типовая, чтобы автор PVS её рассмотрел в своей статье.
Надеюсь, теперь понятно, откуда взялась задача именно в таком виде. Это хороший вид, полезный.
ЕМ>По-хорошему, шаблоны должны быть обобщением на всё, что может потребовать шаблонной обработки, включая генерацию статических таблиц данных во время компиляции. И они должны быть интерфейсом не к препроцессору, а полноценным элементом языка, с адекватными возможностями управления.
Шаблонизация должна быть обобщением на всё, что может потребовать шаблонной обработки. А конкретно template это один из инструментов шаблонизации. Изначально он вообще весь был вокруг typename. Его раздули до недопрепроцессора, а других инструментов шаблонизации не дали (ну и остались устаревшие инструменты из Си). Но мне лично это не кажется правильным. Почему? Да потому, что приведённая в пример задача этим инструментом, как я понял, не решается. Чтобы не начинать заново, типичная она или нет, я сразу скажу, что миллион таких задач приведу.
A>>Очевидное условие — отсутствие паразитного call'а, потому что если ты на него согласен, хватит и простой перегрузки функций.
ЕМ>inline не спасает?
The original intent of the inline keyword was to serve as an indicator to the optimizer that inline substitution of a function is preferred over function call, that is, instead of executing the function call CPU instruction to transfer control to the function body, a copy of the function body is executed without generating the call. This avoids overhead created by the function call (passing the arguments and retrieving the result) but it may result in a larger executable as the code for the function has to be repeated multiple times.
Since inline substitution is unobservable in the standard semantics, compilers are free to use inline substitution for any function that's not marked inline, and are free to generate function calls to any function marked inline. Those optimization choices do not change the rules regarding multiple definitions and shared statics listed above.
То есть, и раньше ничего не гарантировалось, а теперь и подавно.
Тут дело такое. Оптимизаторы массово посходили с ума, и творят страшные вещи. Это касается теперь и Си, к сожалению. А значит, они могут и для явно записанных пар сравнений сгенерировать функцию и её вызов. Я считаю, что чтобы с этими волками жить, надо по-волчьи выть. А именно, писать тот код, который максимально чётко показывает, что ты хочешь. И если оптимизирующий компилятор сделал что-то, чего ты не хочешь, надо ругаться с автором компилятора. Так делает Линус, так делают разные программисты из статьи, на которую я дал ссылку.
А если ты явно описываешь функцию, пусть даже помеченную inline, то ругаться уже бесполезно. Тебя ткнут носом в стандарт, и спросят, на что ты жалуешься.
A>>Альтернативой был бы нормальный препроцессор, а не говно мамонта из языка Си.
ЕМ>Адекватной альтернативой был бы не препроцессор, с его сугубо текстовыми параметрами/подстановками, а нормальные средства условной компиляции. Чтоб шаблон мог узнать у компилятора любые подробности любого из своих параметров, включить в порождаемый код любой из своих элементов в зависимости от условия, если параметров переменное количество — наглядно перебрать их в конструкции вроде "псевдоцикла", работающего во время компиляции, на любом этапе вывести сообщение, и т.п. Примерно так работают классические макропроцессоры.
Это уже спор о терминах. Я имел в виду именно это.
A>>Выше уже написали: попробуйте, если такие смелые. Посмотрим, сколько на нём программистов останется.
ЕМ>Ну вот Вы бы ушли с удобного в целом языка лишь потому, что его компилятор по умолчанию стал выдавать множество предупреждений (которые, если их внимательно прочитать, чаще всего спасают Вас от вероятных косяков, нежели просто надоедают из вредности), любое из которых, или даже все вместе, можно подавить пометками в тексте программы или ключами компилятора?
Я подозреваю, это вопрос из серии "Вы любите тёплое пиво и потных женщин?" с последующим отпуском в ноябре. Конечно же, ответ будет — смотря о чём речь. Кастинги мне нужны как в Си, точка. По очень многим причинам, я их не буду здесь перечислять. Если "пометка в тексте программы" это X_cast<T>, то неважно, что об этом думаю я, это будет конец паразитированию на Си и, как я сильно подозреваю, конец мифу о популярности C++.
A>>Нахера мне нужен язык с ручным управлением памятью, если в нём кастинг и инициализация работают не как в Си?
ЕМ>Вот сейчас вообще не понял. Какая между этим связь? Это ж совершенно ортогональные друг другу вещи.
Какие ты привёл примеры ("столь же "молчаливая" обработка C-style cast, определение неинициализированных переменных без нужды и подобное"), на то я и ответил.
Другое дело, что и Си уже не тот. Си теперь тоже дофига высокоуровневый.
A>>Создатели плюсов поступили очень умно, решив, вот именно, ПАРАЗИТИРОВАТЬ на Си. Если бы они сделали всё то, что ты предлагаешь, у них бы получилось что-то типа D. То есть, дико популярное, но только в очень узких кругах.
ЕМ>По-Вашему, большинство голосишников — маргиналы, стремящиеся уйти от любого контроля только потому, что это контроль, и он теоретически может ограничить их личную свободу?
Не знаю, как большинство (или там сиплюсплюсные меньшинства), а я смотрю на ситуацию так. Есть два разумных варианта: или виртуальная машина (CLR, JVM, V8 и т.п.) и гарантия отсутствия проблем с памятью, или ответственность на мне, но я должен понимать, что происходит, и контролировать ситуацию. Если я объявил переменную, но не проинициализировал, значит под неё выделилась память, и она содержит всякую фигню. Всё, дальше я сам. Если я что-то делаю с указателем, то делаю что-то с указателем. Иначе возникает ситуация, когда компилятор меня ограничивает, но ни за что не отвечает.
Ещё раз: это, к сожалению, в полной мере применимо и к старому доброму Си, как его теперь видят зумеры. Это не эксклюзивно проблема С++.
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Для is is set тоже нужно обобщение на типы. Но это второстепенная задача. Главное там — генерация произвольного количества сравнений.
ЕМ>Если элементов (идентификаторов) не больше, чем количество разрядов в машинном слове, то сравнения вообще не нужны. Нужно преобразовать проверяемое значение в битовую маску, и с помощью команды типа test проверить, входит ли она в множество, образованное совокупностью представленных элементов. Множество (битовая маска) вычисляется на этапе компиляции. Если проверяемое значение заведомо не может быть вне множества, то не нужны даже предварительные сравнения на больше/меньше.
Мне кажется, оптимально остановиться на преобразовании в ==. Исходная задача была в том, что по ошибке вместо результата сравнения использовалось само значение, и с этим надо что-то делать. В общем случае заранее неизвестно, какой там тип и во что выльется ==.
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Идея в том, чтобы писать макросы типа is_in_set на внешнем языке (типа PHP), пропускать через процессор (например, через pre build steps), он их будет разворачивать в нужное количество сравнений, а затем результат подавать на вход компилятору.
ЕМ>Ну сделаете Вы так, а дальше-то что? Задача ж сугубо частная, не так уж много задач можно решить таким образом, чтоб вся эта возня окупилась. Если уж делать механизм, то более-менее универсальный.
Так это и есть универсальное решение.
Кагбе сказать... Вот конкретно начать писать на пыхе плюсовые программы, это я пока всерьёз не рассматриваю. Но всё же тут есть здравое зерно. Оно в том, что мне не нравится, во что превращается язык (и давно превратился). Взять другой ЯП я не могу, т.к. их нет. Написать свой я тоже не могу, т.к. я ваще не умею писать языки прикладник. Да и глупо это. Кто мне за такое заплатит.
Но можно потихоньку писать макросы на верхнем языке просто по мере написания прикладного кода. Я и раньше писал всякие библиотеки, в т.ч. библиотеки макросов. Получится такой квазиязык.
A>>Это не самая практичная задача, а просто пример того, что язык и его процессор должны уметь делать.
ЕМ>В том-то и дело, что подобные решения всегда будут лишь частными. Чтоб можно было делать удобные и эффективные решения для разных задач, язык должен, с одной стороны, позволять извлекать из компилятора информацию о компилируемой программе, а с другой стороны — применять эту информацию для порождения других элементов программы.
Оно не частное, а общее.
Частный тут только пример. Не могу вспомнить, откуда он, с этого форума, или на Хабре видел, или ещё где, но вот недавно совсем обсуждался вопрос с гардами, какой-то там компилер, как оказалось, без них не может. И спрашивается, как жить. Таскать и прагму, и гарды? А я взял и обобщил: нужна вставка в произвольные места, со стеком, чтобы разруливать вложенности. Если это делать через препроцессинг, конечно.
Здравствуйте, Alekzander, Вы писали:
A>когда пишущий на C++ прибегает ко встроенному Си
Это бессмысленная формулировка. Нет в C++ никакого "встроенного Си" — есть только конструкции, "унаследованные от C", "совместимые с C" и т.п. Иначе придется признать, что использование любых фундаментальных типов (кроме bool), и любой арифметики над ними, операции присваивания, точки с запятой и прочего — это "прибегание ко встроенному Си".
И даже говорить, что используются приемы "в стиле C" или "в парадигме C" тоже бессмысленно, ибо сам по себе C++ никаких определенных стилей/парадигм не предполагает.
A>этот выбрал потому, что он рядом, в этом же форуме, его все видели, и настоящие эксперты (не то, что я) привели какие-то решения, высоко оценённые другими экспертами.
Я бы сказал, что в вашем обсуждении народ просто развлекался для разминки мозгов. Одни это любят, другие не понимают. Я вот тоже считаю, что напрягаться для решения задачи имеет смысл, когда задача возникла более-менее естественным путем, а не когда ее создали искусственно. В жизни и так хватает задач, которые возникают сами собой, чтобы отвлекаться еще и на решение специально созданных — напоминает анекдот про гамак и лыжи.
A>Этот пример достаточно типовой, чтобы его привёл автор исходной статьи, тот который из PVS.
Насколько я понял, он как раз не типовой, а всего лишь показательный. Где подобные длинные цепочки сравнений можно увидеть в товарных количествах?
A>медицина в эту сторону не копает. Знаешь, почему? Официальный ответ: это не нужно.
Это Вы теорий заговора начитались. Медицина в эту сторону копает с 80-х — то есть, со времен, как только вирус был выделен. Но все прогнозы пока неутешительны. Даже с вирусом простого герпеса, который куда сильнее локализован, пока справиться не могут — слишком сложно.
A>Пока ты принимаешь антиретровирусную терапию, ты будешь здоров (не разовьётся СПИД, не сократится жизнь и т.д.).
Угу, а когда у тебя (или у твоего государства) нет денег на достаточное количество препаратов, ты не принимаешь АРТ. И все, у кого тоже нет денег (или кого не смогли заставить), тоже не принимают. Но они (внезапно) не берут на себя обязательства поддерживать строгий моральный облик, и активно участвуют в распространении вируса.
С тех пор, как стало понятно, что СПИД — это не просто болезнь, а пандемия, главной задачей стало сдерживание ее распространения, а отнюдь не продление жизни инфицированных. С точки зрения любого государства, было бы гораздо удобнее, чтобы инфицированные умирали как можно быстрее, успевая заразить как можно меньше других. Вот тогда мировая фарма действительно особо не напрягалась бы с поиском способов лечения.
A>Врачи не очень заинтересованы в том, чтобы люди были здоровы. Они заинтересованы в том, чтобы люди лечились.
Вы путаете врачей с "психологами", "психотерапевтами", "целителями" и подобными. Даже в платном медцентре типичный врач не станет умышленно затягивать лечение конкретного пациента, ибо вновь заболевших всегда в достатке. А типичный врач в поликлинике все равно не заработает больше, если пациент придет к нему десять раз вместо трех. Наоборот — он предпочел бы, чтоб пациент не приходил даже во второй раз.
A>Вот и авторам статических анализаторов не нужно, чтобы ты писал здоровый код. Ведь тогда анализаторы перестанут находить у тебя ошибки, а ты перестанешь их покупать.
Судя по активности рекламы того же PVS-Studio, его не очень-то покупают. Я, например, этими анализаторами вообще не пользуюсь.
A>каком виде надо записывать такие сравнения, чтобы эта ошибка стала невозможной?
"Ни в каком, бл#! Теперь — в твердом переплете".
A>Как выработать здоровую привычку для здорового кода? Такую, как Йода-сравнения, например.
В таких привычках нет ничего здорового. Это просто очередной кривой костыль, на безрыбье. С тех пор, как компиляторы начали выдавать предупреждения на потенциально опасное присваивание (где-то с 90-х, если не ошибаюсь), это задомнапередное сравнение полностью потеряло смысл.
A>Надеюсь, теперь понятно, откуда взялась задача именно в таком виде. Это хороший вид, полезный.
ЕМ>>По-хорошему, шаблоны должны быть обобщением на всё, что может потребовать шаблонной обработки, включая генерацию статических таблиц данных во время компиляции. И они должны быть интерфейсом не к препроцессору, а полноценным элементом языка, с адекватными возможностями управления.
A>Его раздули до недопрепроцессора
Что значит "до недопрепроцессора"? Любой препроцессор в ЯВУ — по определению убогий костыльный инструмент, применяемый от безысходности, когда нет ресурсов делать адекватный анализатор/генератор кода, а работать надо. Что сишний, что плюсовый — яркие примеры принципа "нет ничего более постоянного, нежели временное".
A>а других инструментов шаблонизации не дали (ну и остались устаревшие инструменты из Си). Но мне лично это не кажется правильным.
По-моему, это не кажется правильным любому, для кого жонглирование побочными эффектами шаблонов не является самоцелью. Особенно тем, кому доводилось видеть, или хотя бы воображать, более адекватные инструменты.
A>потому, что приведённая в пример задача этим инструментом, как я понял, не решается.
Как и многие другие, куда более актуальные. Хотя даже не сомневаюсь: если заинтересовать ею "шаблонных хакеров" во главе с Александреску, Степановым и иже с ними, через некоторое время они родят внешне приемлемое решение, но вот реализацию его будет лучше не смотреть на ночь.
A>Оптимизаторы массово посходили с ума, и творят страшные вещи. Это касается теперь и Си, к сожалению.
Подобные тексты советую читать с изрядной долей скептицизма. Их авторы традиционно путают особенности реализаций, которые зачастую бывает удобно и полезно использовать именно для конкретных платформ, с условной "С-машиной", которую описывает стандарт. Они хотят странного — чтоб стандарт одновременно обеспечивал и неограниченную переносимость, и предельную эффективность любой конкретной реализации, и чтоб нигде не возникало UB. А это принципиально невозможно — либо абстракция, либо конкретика, третьего не дано.
Собственно, унихоиды сами загнали себя в эту ловушку, поставив во главу угла исходные тексты, вместе с крайней желательностью (а зачастую — и необходимостью) собирать их заново в каждой отдельной системе. Пока у C не было стандартов, исходники набивались #if'ами, учитывающими особенности отдельных реализаций компилятора/линкера. С появлением стандартов стало возможным избавиться от части условий, но тут (внезапно) выяснилось, что стандарты не одобряют хаков. А среди сишников-унихоидов как раз довольно много тех, у кого "это моя программа! это моя машина! не сметь диктовать мне, что я могу делать, а что нет!". Но они ж пишут не только для себя, однако привычки настолько укореняются, что контролировать их непросто.
A>они могут и для явно записанных пар сравнений сгенерировать функцию и её вызов.
Если это хотя бы не менее эффективно, чем последовательный код — почему нет? А если вдруг менее, то с какой стати оптимизатору намеренно ухудшать эффективность?
A>чтобы с этими волками жить, надо по-волчьи выть. А именно, писать тот код, который максимально чётко показывает, что ты хочешь.
Дык, волки тут ни при чем — к такому имеет смысл стремиться всегда и везде, независимо от. Чем более ясно выразишь свои идеи и намерения, тем выше вероятность, что тебя поймут правильно. Именно к этому я всегда и призываю в развитии любых ЯП. И для этого вовсе не обязательна "исходная" многословность, вроде паскалевских begin/end — запись может быть и лаконичной, лишь бы была возможность развернуть ее в удобночитаемую форму при нужде.
A>И если оптимизирующий компилятор сделал что-то, чего ты не хочешь, надо ругаться с автором компилятора. Так делает Линус, так делают разные программисты из статьи, на которую я дал ссылку.
Логично. Поэтому очень желательна возможность управления оптимизацией на "тонком" уровне, а не только через ключи компилятора.
A>А если ты явно описываешь функцию, пусть даже помеченную inline, то ругаться уже бесполезно. Тебя ткнут носом в стандарт, и спросят, на что ты жалуешься.
На этот случай в популярных реализациях есть атрибуты вроде __forceinline. По-хорошему, их лучше бы внести в стандарт, но "коллектив авторов", среди которых почти сплошь прикладники-абстракционисты, будет активно возражать.
A>Это уже спор о терминах. Я имел в виду именно это.
Препроцессор — он потому и "пре", что заканчивает свою работу еще до начала следующей стадии (анализа кода компилятором). Даже если он совмещен с компилятором, то должен работать на чисто текстовом уровне, сразу после выделения минимально возможных синтаксических конструкций. По-хорошему, приличный макропроцессор такого типа полезен в любом языке, и в C/C++ тоже не помешал бы, благо реализуется достаточно просто.
A>Кастинги мне нужны как в Си, точка. По очень многим причинам, я их не буду здесь перечислять.
А было бы интересно. У меня не самые примитивные программы, но от преобразований что в стиле C, что в "функциональном" плюсовом, я избавился достаточно давно, и никаких сколько-нибудь заметных напрягов это не потребовало.
A>Если "пометка в тексте программы" это X_cast<T>, то неважно, что об этом думаю я, это будет конец паразитированию на Си и, как я сильно подозреваю, конец мифу о популярности C++.
Еще интереснее. Что ж и Вы, и другие "паразиты", такого делаете, что переход на X_cast<> может заставить Вас отказаться от языка? У вас эти преобразования в каждой второй строке? Или хотя бы в каждой пятой?
A>>>Нахера мне нужен язык с ручным управлением памятью, если в нём кастинг и инициализация работают не как в Си? A>Какие ты привёл примеры ("столь же "молчаливая" обработка C-style cast, определение неинициализированных переменных без нужды и подобное"), на то я и ответил.
Увы, я по-прежнему не могу понять, о чем именно идет речь.
A>и Си уже не тот. Си теперь тоже дофига высокоуровневый.
В нем от "высокоуровневости" все больше синтаксического сахара. Да, позволяет более изящно записывать отдельные конструкции. Но при усложнении программы сложность кода растет все так же. Возможностей сколько-нибудь удобно комбинировать сущности между собой, как в C++, по-прежнему нет. И не будет, скорее всего.
A>>>Создатели плюсов поступили очень умно, решив, вот именно, ПАРАЗИТИРОВАТЬ на Си. Если бы они сделали всё то, что ты предлагаешь, у них бы получилось что-то типа D. То есть, дико популярное, но только в очень узких кругах.
ЕМ>>По-Вашему, большинство голосишников — маргиналы, стремящиеся уйти от любого контроля только потому, что это контроль, и он теоретически может ограничить их личную свободу?
A>или виртуальная машина (CLR, JVM, V8 и т.п.) и гарантия отсутствия проблем с памятью, или ответственность на мне, но я должен понимать, что происходит, и контролировать ситуацию.
Промежуточные варианты не рассматриваются? Например, возможность привязки к конкретным реализациям VM, или автоматизация управления памятью?
A>Если я объявил переменную, но не проинициализировал, значит под неё выделилась память, и она содержит всякую фигню. Всё, дальше я сам.
Почему не возникает резонного вопроса "как построить программу так, чтобы объявить переменную, но не инициализировать ее, было технически невозможно"? На худой конец — чтобы компилятор был обязан обнаруживать все подобные ситуации, и генерировать ошибку (а не предупреждение), если переменная в тексте явно не снабжена хорошо заметной пометкой типа "да, я нарочно объявил ее здесь, и буду за это отвечать". Тогда что компилятор, что внешний анализатор, могли бы для любой программы показать список таких пометок, чтоб при поиске причин глюков знать, куда смотреть в первую очередь.
A>Если я что-то делаю с указателем, то делаю что-то с указателем. Иначе возникает ситуация, когда компилятор меня ограничивает, но ни за что не отвечает.
Почему не отвечает? Целью любых стандартов, что в производстве, что в программировании, являются повышение надежности и предсказуемости — к сожалению, часто в ущерб экономичности. Не нужно бороться со стандартизацией, как явлением — нужно предусматривать возможность явно и хорошо заметно декларировать "я намеренно отступаю от стандарта". И тогда сразу видно, кого бить по наглой рыжей морде — компилятор, который соблюдает стандарт ценой снижения эффективности, или программиста, взявшего на себя больше, чем он смог вынести.
A>в полной мере применимо и к старому доброму Си, как его теперь видят зумеры. Это не эксклюзивно проблема С++.
Совершенно верно: зумеры хотят, чтоб все стало как можно проще, зубры хотят, чтоб все осталось, как раньше. Вместо того, чтобы искать разумный компромисс, обе стороны уперлись в "нет, должно быть только по-нашему, и никак иначе".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я бы сказал, что в вашем обсуждении народ просто развлекался для разминки мозгов. Одни это любят, другие не понимают. Я вот тоже считаю, что напрягаться для решения задачи имеет смысл, когда задача возникла более-менее естественным путем, а не когда ее создали искусственно. В жизни и так хватает задач, которые возникают сами собой, чтобы отвлекаться еще и на решение специально созданных — напоминает анекдот про гамак и лыжи.
Я же не виноват, что ты видел мало кода в своей жизни.
Эти сравнения сплошь и рядом встречаются, например, при поддержке железа. Вендор выпустил модельную линейку, в которой у каждой модели уникальный профиль поддержки багофич, ты в рантайме запросил ModelId и вперёд. Это пример из проекта, где is_in_set() встречался буквально десятками.
Збс, конечно. "Я не видел, значит это никому не надо".
ЕМ>Это Вы теорий заговора начитались. Медицина в эту сторону копает с 80-х — то есть, со времен, как только вирус был выделен. Но все прогнозы пока неутешительны. Даже с вирусом простого герпеса, который куда сильнее локализован, пока справиться не могут — слишком сложно.
Эта теория заговора называется "рыночная экономика". Фармкомпании вкладывают деньги в то, что принесёт деньги, быстро и много. Ты явно не читаешь обзоры этого бизнеса.
A>>каком виде надо записывать такие сравнения, чтобы эта ошибка стала невозможной?
ЕМ>"Ни в каком, бл#! Теперь — в твердом переплете".
Мне уже понадоела шымжа-стайл философия, если честно. Записав код как foo(v, 1, 2, 3), ты больше не сможешь пропустить v ==. Да, это всё, чего мы добились. Кофе такой код не варит, ото всех болезней не лечит, на бирже не торгует, в ж не целует. Он не нужен.
A>>Как выработать здоровую привычку для здорового кода? Такую, как Йода-сравнения, например.
ЕМ>В таких привычках нет ничего здорового. Это просто очередной кривой костыль, на безрыбье. С тех пор, как компиляторы начали выдавать предупреждения на потенциально опасное присваивание (где-то с 90-х, если не ошибаюсь), это задомнапередное сравнение полностью потеряло смысл.
Хорошо, когда ты все компиляторы повидал. А если чего-то и не видал, то в этом нет смысла.
А я вот ещё недавно собирал плюсовую программу под одну железяку очень специальным компилятором, который ворнингами не баловал. Не говоря уж о том, что если у тебя в одном проекте код на плюсах и каком-нибудь интерпретируемом DSL, тебе лучше выработать здоровую привычку всегда писать единообразно.
ЕМ>Как и многие другие, куда более актуальные. Хотя даже не сомневаюсь: если заинтересовать ею "шаблонных хакеров" во главе с Александреску, Степановым и иже с ними, через некоторое время они родят внешне приемлемое решение, но вот реализацию его будет лучше не смотреть на ночь.
Вот это точно.
A>>Оптимизаторы массово посходили с ума, и творят страшные вещи. Это касается теперь и Си, к сожалению.
ЕМ>Подобные тексты советую читать с изрядной долей скептицизма. Их авторы традиционно путают особенности реализаций, которые зачастую бывает удобно и полезно использовать именно для конкретных платформ, с условной "С-машиной", которую описывает стандарт. Они хотят странного — чтоб стандарт одновременно обеспечивал и неограниченную переносимость, и предельную эффективность любой конкретной реализации, и чтоб нигде не возникало UB. А это принципиально невозможно — либо абстракция, либо конкретика, третьего не дано.
А я советую прочитать примеры, которые они приводят. Переписки, в т.ч. Если раньше скандалов с хипстооптимизаторами не было, а сейчас они есть, значит что-то изменилось.
ЕМ>Логично. Поэтому очень желательна возможность управления оптимизацией на "тонком" уровне, а не только через ключи компилятора.
Такая возможность в данном случае называется "явный (не)вызов функции". Если ты в явном виде вставил вызов функции, ты больше не можешь жаловаться, что оптимизатор сгенерировал call.
ЕМ>На этот случай в популярных реализациях есть атрибуты вроде __forceinline. По-хорошему, их лучше бы внести в стандарт, но "коллектив авторов", среди которых почти сплошь прикладники-абстракционисты, будет активно возражать.
__forceinline нужен не для этого случая, лол. А для случая, обратного ему. Его, конечно, хорошо было бы стандартизировать. А кто тут абстракционист, советую перечитать свою философию про "только дурак будет пользоваться системой, защищающей от ошибок" в ответ на конкретный вопрос.
Здравствуйте, Alekzander, Вы писали:
A>Это пример из проекта, где is_in_set() встречался буквально десятками.
Я правильно понимаю, что Вы одобряете использование множественных сравнений "десятками", без стремления преобразовать их в более адекватный вид (switch, таблицу или битовые маски), и выступаете лишь за то, чтобы подобный кондовый код писали и дальше, лишь бы делали в нем меньше опечаток?
A>Эта теория заговора называется "рыночная экономика". Фармкомпании вкладывают деньги в то, что принесёт деньги, быстро и много.
Какие-то компании вкладывают деньги иначе?
А фармкомпании вкладываются в разработку АРТ прежде всего потому, что есть госзаказы на нее, объем которых значительно больше, чем совокупность индивидуальных. Они и стабильнее, и расценки там можно предложить выше. Так вот получилось, что препараты для достаточно эффективной АРТ удалось создать раньше, чем препараты для полного излечения. На этом безрыбье любому государству выгоднее сдерживать у себя эпидемию с помощью АРТ, чем ждать, пока сделают радикальную терапию.
Тем не менее, над радикальной терапией продолжают работать, и достаточно интенсивно. Просто потому, что АРТ ни разу не безвредная — она лишь заменяет относительно скорую и весьма неприятную смерть от СПИДа более длительной, но не слишком приятной жизнью на АРТ. Мало у кого получается сидеть на АРТ и продолжать безмятежно радоваться жизни.
A>Ты явно не читаешь обзоры этого бизнеса.
Я не читаю текстов, у которых явно прослеживается цель создания определенной точки зрения и/или позиции у читателя.
A>Записав код как foo(v, 1, 2, 3), ты больше не сможешь пропустить v ==.
Но по-прежнему смогу сделать десятки-сотни других ошибок, в том числе логических и неочевидных.
A>Да, это всё, чего мы добились.
Именно — изощренными приемами, к которым есть резонные вопросы (тот же возможный вызов) понизили вероятность отдельно взятой ошибки, при том, что эту самую вероятность никто не оценивал. То есть, внезапно обнаружили, что есть какой-то риск, и приняли активные меры для того, чтобы этого риска избежать. А о том, что рядом могут быть (и, скорее всего, есть) гораздо более высокие риски, предпочли не думать. Это распространенный подход — предотвращать не то, что наиболее вероятно, а то, что почему-то больше всего пугает.
A>А я вот ещё недавно собирал плюсовую программу под одну железяку очень специальным компилятором, который ворнингами не баловал.
Если Вы эту программу не писали специально под эту железку, и код более-менее переносимый, то его правильность можно проверять более умным компилятором. А если именно специально под нее, то сколько можно найти таких компиляторов? Ну не повезло конкретно Вам, зачем же отстаивать приемы, которые для большинства давно потеряли актуальность?
A>если у тебя в одном проекте код на плюсах и каком-нибудь интерпретируемом DSL, тебе лучше выработать здоровую привычку всегда писать единообразно.
Хм, и сколько таких DSL, где можно писать код "единообразно" с плюсовым, чтоб это не просто было в одном стиле, а действительно уберегало от ошибок?
A>А я советую прочитать примеры, которые они приводят.
Читал я подобные переписки. В одном, помнится, дошли аж до возмущения тем, что в цепочечном сравнении вроде Вашего оптимизатор вставил ветвление, которое "снижает быстродействие", а не преобразовал выражение так, чтобы обойтись арифметикой и логикой. И никто ведь не вспомнил, что компилятор, по-хорошему, вообще не имеет права вычислять правые выражения до того, как будут получены и проверены результаты левых.
Повторю: бороться нужно не с оптимизациями, как таковыми, а с их неочевидностью. То есть, настаивать на поддержке в языке (или хотя бы в компиляторах) средств, позволяющих избежать нежелательных оптимизаций. На худой конец — чтоб компилятор предупреждал, что конструкция кажется ему бессмысленной, и он как-то редуцирует.
ЕМ>>Логично. Поэтому очень желательна возможность управления оптимизацией на "тонком" уровне, а не только через ключи компилятора.
A>Если ты в явном виде вставил вызов функции, ты больше не можешь жаловаться, что оптимизатор сгенерировал call.
Если я вставил вызов функции с __forceinline — могу.
A>__forceinline нужен не для этого случая, лол. А для случая, обратного ему.
Я запутался в Вашей логике. Вы начали с опасения о том, что вызов функции не развернется в код в точке вызова, а будет сгенерирован call, и inline не гарантирует непосредственной вставки. Я предложил __forceinline, но "это снова не то". А что нужно-то?
Для "случая, обратного ему" VC++ есть __declspec(noinline). Вроде и у GCC тоже такое есть.
Здравствуйте, qqqqq, Вы писали:
Q>Так это не только совместимость C++ с С а и между разными компиляторами на С++ тоже, так называемый name mangling у каждого свой.
Я уже дважды повторял, что речь не об этом. С разморозкой!
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если элементов (идентификаторов) не больше, чем количество разрядов в машинном слове, то сравнения вообще не нужны. Нужно преобразовать проверяемое значение в битовую маску, и с помощью команды типа test проверить, входит ли она в множество, образованное совокупностью представленных элементов. Множество (битовая маска) вычисляется на этапе компиляции. Если проверяемое значение заведомо не может быть вне множества, то не нужны даже предварительные сравнения на больше/меньше.
И при смене разрядности из-за смены платформы переписывать весь код? Спасибо, проходили, мне такое не надо.
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>И при смене разрядности из-за смены платформы переписывать весь код? ЕМ>Зачем весь?
Если автор привязывает код к архитектуре, то он редко делает это только в одном месте. Хотя, конечно, бывают исключения.
Здравствуйте, B0FEE664, Вы писали:
BFE>Если автор привязывает код к архитектуре, то он редко делает это только в одном месте. Хотя, конечно, бывают исключения.
Зависит от автора. Ну и битовые операции есть на любой архитектуре. Если софт писан во времена расцвета 32-разрядной, какова вероятность, что приспичить собирать под 16-разрядную?
BFE>К тому же не забываем про фатальный недостаток
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В чем может быть ценность этой совместимости, кроме поощрения ленивых и малограмотных? Может, я чего не понимаю?
Я бы действовал наоборот, под лозунгом: "Пусть расцветают сто цветов!"
Ничего, кроме отсутствия ресурсов, не мешает добавить с С++:
extern"D"
{
// code на D
}
extern"Java"
{
// code на Java
}
extern"Rust"
{
// code на Rust
}
Перед использованием подобных конструкций я бы сперва посмотрел, в какой код они компилируются. Иначе легко можно нарваться на активное использование динамической памяти.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Хм, а в чем смысл наличия повторяющихся значений в цепочках сравнений, объединенных ||? Чтоб было более загадочно? ЕМ>switch здесь как раз хорош тем, что будет ругаться на повторяющиеся значения, и тем наведет на мысль, что здесь что-то не так. Смысл тут.
то возникнет ошибка компиляции на платформах, где EAGAIN == EWOULDBLOCK. Тогда как на платформах, где это разные значения, все будет нормально.
При этом тупое сравнение (errno == EAGAIN || errno == EWOULDBLOCK || ...) будет нормально компилироваться всегда.
ЕМ>Перед использованием подобных конструкций я бы сперва посмотрел, в какой код они компилируются. Иначе легко можно нарваться на активное использование динамической памяти.
Да ну откуда тут может взяться динамическая память?
Тут магия в том, что мы в contains передаём constexpr, и вместо вызова код будет развёрнут в сравнения, как и требуется по условиям задачи? Или я неправильно понимаю?
