LINUX.ORG.RU

юнионы в C++

 


2

4

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

Даже интересует не столько то, насколько они используются в существующих программах, а есть ли примеры программ, где хорошие средства плюсов сконсолидировались и поставили заслон от опасных конструкций Си, позволив полностью избежать их использования и избавиться от типичных ошибок Си. Можно ли так написать что-то существенно сложное? Сделано ли это в любимых библиотеках (Буст, QT и иже с ними)? Вторая часть вопроса - это неопределённое поведение. В Си его много. Это подаётся как фича, но с точки зрения безопасности это дыра. Меньше ли неопределённого поведения в С++?

Есть две полярные точки зрения на вопрос:

а) С++ перекрывает Си, поэтому там всё сделано по-другому, поэтому безопасность выше б) С++ - наследник Си и в целом наследует его недостатки.

Поскольку я мало пишу на Си и ещё меньше на Си++, у меня нет сложившегося мнения на эту тему. А у ЛОРа наверняка есть мнение, даже несколько.

★★★★★

Последнее исправление: xaizek (всего исправлений: 4)

Ответ на: комментарий от x86_64

Я подумал, что переманить пытаетесь. :)

ТС-а?! Чур меня…. У нас порог вхождения сильно повыше чем в плюсы будет.

Насчет Реал тайм я не спец. Но по рассказам местного народа там в ход идет много чего, от плюсов до лиспа на плисках.

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от den73

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

Прямо идеальный пример.

И вы уперены, что JS умерет?

x86_64 ★★★
()
Ответ на: комментарий от den73

но VS Code меня устраивает, в то время как IDE, написанные на Java - слишком тормозные, а написанные на C++ - просто слишком убогие (потому что на убогом

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

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

Именно поэтому GCC, LLVM, ICC, EDG и другие компиляторы, опять же, мировой известности, написаны на С++.

Числодробилки, внезапно, пишут тоже и на лиспе, и даже на Обероне (допилив сам Оберон, т.к. его легко расширять).

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

Siborgium ★★★★★
()
Ответ на: комментарий от den73

Неинициализированная матрица для числодробилки, забитая мусорными числами - это же прекрасно!

И? Такое сразу отсеится тестами.

Вот буквально до первой пилотной версии не дойдет.

А в пилотной версии еще на простых моделях косяк может всплыть.

x86_64 ★★★
()
Ответ на: комментарий от den73

Бггг, а без перехода на личности и фантазий о проблемах с безопасностью при написании числодробилок у Вас есть что сказать?:-)

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

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

Ну ты во-первых себя не особо хорошо показал в разговоре, во-вторых, я работы на плюсах не ищу, у меня вообще с работой всё норм.

den73 ★★★★★
() автор топика
Ответ на: комментарий от x86_64

Ну хоть на полезными утилитами, нивелирующими недостатки работать будете?

Я над ними на работе за деньги работаю. В свободное же время пишу телеги :)

den73 ★★★★★
() автор топика
Ответ на: комментарий от Siborgium

Именно поэтому GCC, LLVM, ICC, EDG и другие компиляторы, опять же, мировой известности, написаны на С++.

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от Siborgium

Нет, ты не отличаешь IDE от текстового редактора с плагинами. Не существует IDE на электроне.

Ну можно и в эту сторону поспорить. В VS Code есть всё, что нужно мне. Да, там нет рефакторингов. И только. Автоформат кода, переходить к определению и отлаживаться - можно, легко, более-менее работает, для нескольких языков. При том, в эклипсе я сломался на попытке наладить под себя шрифты.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Ну бывают разные традиции

Фантазировать на ЛОРе, например.

С моей стороны приведен целый ряд примеров того, что есть, работает и развивается.

С твоей – сливы и фантазии о прекрасных языках будущего, не взлетевших 30 лет назад, но обязательно взлетящих уже вот почти завтра.

Siborgium ★★★★★
()
Ответ на: комментарий от x86_64

И вы уперены, что JS умерет?

Попытки его обойти налицо. Тут и typescript, и dart, и всякие технологии для создания приложений вне браузера. В этом ситуация вполне подобная сям и плюсам. Умрёт? Ну хз что будет вообще через 5 лет. Технология, набравшая массу, живёт долго, примеры только что были, тот же Кобол и Фортран с его блас-лапаком. То же касается и сей-плюсов. Но это не значит, что с ними не нужно бороться, расчищать место под будущее.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Ну можно и в эту сторону поспорить. В VS Code есть всё, что нужно мне. Да, там нет рефакторингов. И только.

Я не спрашивал, что есть в VSCode, и чего нет. Я не спрашивал, хватает ли тебе того, что там есть.

Автоформат кода, переходить к определению и отлаживаться - можно, легко, более-менее работает, для нескольких языков.

Все это есть в виме. Это не делает VSCode IDE. Это делает VSCode текстовым редактором, крайне неэффективно использующим приклеенные изолентой и соплями сторонние инструменты. Это чудовищные тормоза по сравнению с реальным IDE.

При том, в эклипсе я сломался на попытке наладить под себя шрифты.

Боже, какая чушь. Какое отношение имеют шрифты к IDE?

Siborgium ★★★★★
()
Ответ на: комментарий от Siborgium

Я перестаю отвечать тем, кто хамит, называет меня психом или априори рассуждает, что я что-то не осилю, или использует манипулятивные приёмы. В этих случаях я подаю жалобу и прерываю разговор. Это не значит, что я слился, это значит, что есть правила разговора, которые нужно соблюдать, если есть желание со мной поговорить. Когда мне указали, что Го не потомок Активного Оберона, я это проверил и признал свою неправоту, хотя мне даже сначала показалось, что это манипулятивный приём, а на самом деле чел показал изъян в моей собственной логике, в итоге я ему сказал спасибо.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от Siborgium

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

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 3)
Ответ на: комментарий от kvpfs

const It cit;
то второй нельзя будет итерировать (он ведь константый)

const_It cit
отличие между ними лишь в том, что второй хранит указатель на константые данные, а первый нет.

С отличиями согласен. Вот только давай запишем то же самое на уровне типов

const<iterator<int>> cit1;

iterator<const<int>> cit2;
Crocodoom ★★★★★
()
Ответ на: комментарий от den73

Ок, мой коммент стерли, я его перефразирую.

Я догадываюсь зачем Вы пишете телегу. Если наш Институт привлекут в качестве экспертной организации, то я сделаю все, что бы Ваша разработка не получила финансирования/внедрения.

До этой дискуссии я к Вам и Вашей разработке относился со сдержанным интересом, скорее положительно. Но Вы сумели изменить мое мнение.

Хотя возможно неправильно проецировать отношение к разработчику на его творение, но языков программирования довольно много, выбор велик.

ЗЫ и да, надо отвечать даже за то что ты сказал в интернете каким то анонимам.

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от den73

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

Ты знаешь как настроить шрифты в интерфейсе vscode?

На панельках и менюшках?

x86_64 ★★★
()
Ответ на: комментарий от AntonI

Жалоба была мной подана за хамские выпады.

Я догадываюсь зачем Вы пишете телегу.

Пока что мимо.

Если наш Институт привлекут в качестве экспертной организации, то я сделаю все, что бы Ваша разработка не получила финансирования/внедрения

Раз да Вас. Приятно чувствовать свою власть и способность её применить для блага!

den73 ★★★★★
() автор топика
Ответ на: комментарий от x86_64

Мне это не было нужно. Потому что в ОС у меня уже как-то настроен нормальный размер шрифта, а в VS Code шрифт всего один (мне пока попадался). А вот в Эклипсе это было реально неприятно.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от bugfixer

Исключительно в теории (нужно специально постараться - тут уж каждый ССЗБ). На практике - не встречал.

Если говорить о практике, то указатели, возвращаемые begin и cbegin могут вообще вести на физически разную память. На разные участки одной памяти — тем более.

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

Crocodoom ★★★★★
()
Ответ на: комментарий от den73

Мне это не было нужно.

Насколько я помню, это было невозможно.

Ваш пример хорошего IDE не удовлетворяет вашим же требованиям к хорошему IDE.

x86_64 ★★★
()
Ответ на: комментарий от den73

Причем здесь власть? Вы хотите сформировать а аудитории отношение к плюсам и Яру - Вам это удалось. Продолжайте в том же духе.

Дальше скучно. Всего хорошего, спасибо за беседу.

AntonI ★★★★★
()
Ответ на: комментарий от x86_64

Если это какая-то попытка меня поймать, то давайте не тратить время: в Eclipse я страдал от шрифтов, в VS Code - нет. Я не знаю, как это получилось и об этом не думаю, пока мне что-то не начинает мешать. В случае VS Code ничего не мешает - это наилучший вариант.

den73 ★★★★★
() автор топика
Ответ на: комментарий от AntonI

Яр уже давно закрыт, 3 года, но про новую разработку не скажу, а то и она под репрессии попадёт. Впрочем, и она уже тоже на грани закрытия. Насчёт отношения к плюсам - вряд ли, я же в основном спрашивал, а мои аргументы, которые я привожу, в общем-то общеизвестны. Либо люди их уже приняли, либо уже отвергли. Интересная оценка результатов моей работы, но тоже мимо :) Вам тоже всего хорошего.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 3)
Ответ на: комментарий от x86_64

В чём прокол? Размер шрифта в текстовых окнах меняется сочетанием клавиш, в т.ч. это распространяется и на логи. ЕМНИП в эклипсе меня доставал мелкий шрифт в логе компиляции. В VSCode этой проблемы нет. Т.е. в VSCode проблемы со шрифтами у меня не было. Допустим, я нечётко сформулировал требования к инструменту, но это мелочь. Если Вас радует, что меня на этом поймали, то примите мои поздравления. Видите, я не сливаюсь, т.к. я не играю в спорт «будь всегда прав и победи всех остальных», а завёл тему, чтобы что-то узнать. Я признаю поражение. Тем не менее, «настоящая IDE» Eclipse доставила мне боль, а «жирный текстовый редактор с болтающимся скотчем» - не доставил. Я на данный момент успешно просматриваю определения, собираю и отлаживаю программы на go, C, java и python в VS Code - всё более-менее работает. Кажется, когда-то и ноду отлаживал. Языки, которые она не осилила - это ocaml и Common Lisp - там только емакс. Но их и эклипс не осилит, 99%. Так что называй хоть редактором, хоть пирожком - оно работает. Да, проблемы были. Но в случае жабы проблемы в VS Code решились почему-то быстрее, чем те же проблемы в JB.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 5)
Ответ на: комментарий от Crocodoom

Если говорить о практике, то указатели, возвращаемые begin и cbegin могут вообще вести на физически разную память.

Вы реально такое встречали?

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

Имхо: очень непрактично. Зачем прятать вот это всё за итераторами? Да, можно заставить работать, и да - можно даже заставить работать во всех случаях включая сохранение всех гарантий [не]инвалидации итераторов присущим node-based containers. Но будет медленно. Если бы мне что-то такое было нужно это был бы какой нибудь отдельный tree_view со своими итераторами и логикой синхронизации внешней по отношению к этим итераторам.

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

Если говорить о практике, то указатели, возвращаемые begin и cbegin могут вообще вести на физически разную память.

Вы реально такое встречали?

Так это встречают все, кто руками реализует кэширование доступа. То есть, сценарий выбора между [дорогим, но mutable] и [дешевым, но r/o] доступом к объекту. И на этот сценарий отлично налазит begin/cbegin, которые, как нам и завещал стандарт, могут иметь разные кишки. Или не налазит?

Зачем прятать вот это всё за итераторами? Да, можно заставить работать, и да - можно даже заставить работать во всех случаях

Ну вот хочется спрятать, почему нет?

был бы какой нибудь отдельный tree_view со своими итераторами и логикой синхронизации внешней по отношению к этим итераторам.

Ну этот tree_view всё равно должен иметь доступ к кишкам tree, то есть быть наследником или там friend. Иначе нельзя обновлять кэш частично, только пересчитывать весь tree. А раз это всё равно «друзья», то зачем плодить сущности, почему не сделать всё в классе tree?

Crocodoom ★★★★★
()
Ответ на: комментарий от Crocodoom

Так это встречают все, кто руками реализует кэширование доступа. То есть, сценарий выбора между [дорогим, но mutable] и [дешевым, но r/o] доступом к объекту. И на этот сценарий отлично налазит begin/cbegin, которые, как нам и завещал стандарт, могут иметь разные кишки. Или не налазит?

А в чём проблема? Ну не учим свой неконстантый итератор кастоваться в константный, это просто не скомпилится. Если разговор о «универсальной» begin(), то range’ы дают возможность кастомизировать их поведение, там все эти ranges::[c]begin() и смежные штуки обзываются «customization point object», или можно специализацию для своего итератора в std:: написать.

PS: хотя не совсем уверен по поводу range’ов, не уверен, что правильно понимаю «customization point object», не факт, что можно свою версию там подставить.

kvpfs ★★
()
Последнее исправление: kvpfs (всего исправлений: 1)
Ответ на: комментарий от AntonI

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

А не затруднит дать ссылочку на статейку - почитать, просто обзорную, просто почитать как примерно это делается.

Silerus ★★★★
()
Ответ на: комментарий от Crocodoom

отлично налазит begin/cbegin

Это очень плохо налазит. Вы не хотите проверять что Ваш cache up-to-date на каждом доступе через итератор, и уж тем более не хотите заставлять его синхронизироваться на каждом доступе (что потенциально может быть очень дорого, несопоставимо дороже чем собственно доступ). Вы хотите это делать в контролируемые моменты времени. Какие именно - зависит от конкретной задачи.

Ну этот tree_view всё равно должен иметь доступ к кишкам tree, то есть быть наследником или там friend.

Вовсе не обязательно. Достаточно из tree заэкспозить read-only всё то что нужно для эффективной синхронизации.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от Silerus

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

В смысле счета - это итерационная процедура, надо ЕМНИП на каждой итерации решать Гельмгольца и патчить маску, в итоге картинка должна отвечать требуемой. Когда длина волны много больше масштаба (размера «пикселя») картинки, маска на картинку не похоже вообще никак. К сожалению иногда маску рассчитать не удается, приходится менять расположение дорожек, транзисторов и пр., которые тоже нетривиально считаются.

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от fluorite

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

про тайпскрипт

Вроде обсуждаем «телегу против плюсов», а не как добавить хоть какую-то типизацию в яваскрипт.

fluorite ★★★★★
()
Ответ на: комментарий от AntonI

спасибо, думал на халяву получить немного знаний, поищу почитаю для общего развития. Спасибо

Silerus ★★★★
()
Ответ на: комментарий от fluorite

Ну просто нельзя же говорить, что vs code написан на плюсах. Правда сейчас нашёл только 17 тыс строк собственно в самом vscode (на typescript). фиг знает, где у них там вся сложность сидит.

Очевидно, что это без плагинов, на счёт node_modules меньше уверен, но вряд ли оно было бы столь тощим.

Кстати, я вот сейчас узнал про существование стандартов CERT C и CERT C++. Кто их исповедует в своей работе? Насколько они помогают от уязвимостей? А от других грабель?

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 3)
Ответ на: комментарий от den73

Там бесполезные с практической точки зрения советы/правила, типа «не используй уже освобождённый объект». Спасибо, не знал. Т.е. эти правила созданы не для написания хорошего кода, а для security code review.

rupert ★★★★★
()
Ответ на: комментарий от den73

Допустим, я нечётко сформулировал требования к инструменту, но это мелочь.

Значит это такой стиль общения, что-то категорично утверждать, вообще не задумываясь над темой.

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

Но в случае жабы проблемы в VS Code решились почему-то быстрее, чем те же проблемы в JB.

В случае жабы они хоть как-то но решаются. А вот с vscode - облом. У меня у монитора разрешение большое - меню и панельки нечитаемы. Хорошо, что все можно командами сделать, но неприятно.

x86_64 ★★★
()
Ответ на: комментарий от x86_64

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

Всего одну? Я знаю ещё парочку.

За такое надо причиндалы отрывать.

За C++ в 2022 году надо отрывать причендалы, согласен.

hateyoufeel ★★★★★
()
Ответ на: комментарий от eao197

А что я могу сделать?

Ответить на вопрос.

То есть, вектора из констант или смешанных значений в STL запрещены.

Зачем вам это?

У меня есть функция, которая берет вектор ссылок на объекты, и возвращает ссылку на второе значение из вектора. Не важно, какая там ссылка: сишная, или reference_wrapper, или unique_ptr, или shared_ptr — чтобы было совсем ясно и конкретно, пусть тип будет char *. Какова должна быть сигнатура функции?
Может быть const char* get_second(const vector<char *>)?
Или же char* get_second(vector<char*>)?
А если я хочу эту функцию применить к вектору из compile-time константных объектов?
const char* get_second(const vector<const char*>)?

Между прочим, официальная позиция — да, копипасть функции с разными аргументами. Вся стандартная библиотека крестов слепена из такой копипасты, например:
https://en.cppreference.com/w/cpp/container/vector/front
Так выглядит почти любой метод чтения, возвращающий ссылки. Слава богу хоть volatile выкинули, иначе бы пришлось четыре копии держать.

Позиция «ссылки не нужны, копируйте значения, так надежнее» имеет право на жизнь, а также намекает на то, что константная ссылка-аргумент нужна только для копирования в non-const объект — возвращать ссылки на аргумент и его поля «плохо». У меня есть ощущение, что авторы стандартной либы тяготеют к такому подходу, однако, как мы все понимаем, он далеко не самый эффективный. Именно потому Qt сделало строки (и куча других объектов) с подсчетом ссылок вместо стандартных — когда у тебя ездит куча объемных объектов (часто неизменяемых) туда-сюда по коду, то копирование на каждый чих приводит к печальному результату. На самом деле, очень многие высокоуровневые ЯП пошли именно по пути подсчета ссылок: Object Pascal, Java, JavaScript, PHP, Python — это из самых попсовых. Правда, реализация строк Qt выглядит откровенно страшненько при чтении сорцов.

Из мемуаров продажника можно узнать, что Страуструп изначально продавал под названием readonly, а позже const, то, что в современном C++ известно как constexpr, то есть, именно compile-time объекты-константы, а не ссылки на константные значения. Более того, начиная с C++14 компилятор умеет автоматически применять constexpr для функций от констант и снимать его, если функция берется от переменных — то есть, constexpr более не подразумевает const, он вообще ортогонален const-у.

Но это сейчас мы такие умные, а в восьмидесятых была ситуация «не знаю, как его сделать, но звучит красиво — давайте внесем в стандарт языка Си». И внесли (теперь вы знаете, как в стандарт попала поддержка GC). И очень долго время под соусом const существовало три независимых вещи:

 — compile-time константы, каковые были во всех остальных языках, например #define x 42;
 — compile-time выражения-функции, например static constexpr int const& x = 42 (обращаю внимание, что это уже ссылка);
 — read-only аргумент-ссылка на ИЗМЕНЯЕМЫЙ объект, void function(const int &x). Да-да, оптимизирующие компиляторы считают, что объект по константной ссылке может измениться в любой момент, что в фундаменте противоречит идее «константы». Иронично, что исходное название модификатора readonly в данном случае подходит лучше.

Когда в обсуждениях эти три сущности перемешиваются под одним ярлыком «const» в виде вопроса «а нужен ли const в C++», то начинается «кто в лес, кто по дрова», каждый думает про что-то свое. Это маркетологи любят штуки вроде «мультиварка-ядерный реактор, которая снабдит ваше село сотней киловатт электричества, приготовит завтрак вашему ребенку, и отведет ребенка в школу» — но мы тут ничего не продаем, а разбираемся, что же всучили нам маркетологи в кокаиновом угаре, и что с этим теперь делать.

Но вот же ж константная ссылка, или меня уже глючит?

Так вы же сам объект item не меняете

Вот тебе сюрприз: когда я делаю vector[23] = std::string("asd") — я тоже не меняю объект vector, он может быть константной ссылкой. Тем не менее, разрабы STL запретили делать присвоение по индексу у const vector. Просто «потому что». А в Qt я могу поменять строку, ссылающуюся на разделяемый неизменяемый объект, и при этом произойдет copy-on-write. Итого разрабы стандартной сделали некое отрывистое впечатление, что const в C++ действительно работает, хотя на самом деле работает оно на весьма ограниченном числе сценариев, которые они тщательно отобрали, сделав остальные «ненужно».

byko3y ★★★★
()
Ответ на: комментарий от eao197

Пф-ф-ф, можно вообще все поля у всех объектов сделать mutable — очень удобно будет

Кому будет удобно?

Всем. Потому что const Type и Type станут взаимозаменяемыми.

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

Я отвечал DarkEld3r-у, что «помогает» оно только если за тебя кто-то уже очень много налюбился с реализацией и тщательной подборкой интерфейсов. Впрочем, при чем тут const? Вот Qt не использует подход стандартной либы C++, в Qt данные объектов константны и изменяемы одновременно. Им типа const не помогает? Оно помогает только если сделать вид, что кроме STL больше готовых решений не существует, что синхронизации нет, подсчета ссылок нет, персистентных структур нет, кэшей нет — пердолим дальше отдельные байтики по указателям через интерфейсы с повышенной надежностью (привет разрабам Rust).

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

Задумался. Пришел к выводу — const не нужен. Каждый раз, когда что-то пишется const — в следующую наносекунду откуда-то магическим образом прилетает переменная без const, которую нужно засунуть в const функции. Опять-таки, разрабы стандартной либы в ряде случаев просто ничего не смогли с этим придумать, в ряде случаев начиная с C++20 в стандартной либе у методов наконец появились constexpr модификаторы, которые сами разбираются, вычисляемы ли они в compile-time или нет, а остальные случаи «не нужны».

Так что за пример такой с константным контейнером (списком константных значений), в котором этом самый константный контейнер нужно модифицировать? Смысл его извращения от меня ускользает

Я предыдущим сообщением уже частично ответил, повторюсь: std::list<const char*>. В идеологии STL интрузивным оно не может быть в принципе. Можно было бы сделать std::list<char*>, но, ололо, это же небезопасно, вдруг кто-то засунет туда настоящую константу, а кто-то другой ее изменит — приложение упадет с segfault. В итоге, как ни прыгай — получаются сорта говна, const поломано by-design, и на самом деле ты сам склоняешься к «const не нужен», но почему-то боишься пойти до конца.

byko3y ★★★★
()
Ответ на: комментарий от alysnix

это все равно что

auto lp = item.b;
*lp = std::string(...);

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

это значит - изменить то, на что указывает указатель item.b. то есть сам item не меняется

Я всеми конечностями за то, чтобы признать наконец const T& модификатором доступа к имени переменной, а не модификатором типа.

Эта путаница актуальна и для деления «ссылка-указатель», которая перекочевала в C++ из Cи, и решить ее не удалось (потому что никто ее и не решал, LOL).

Но вместо того, чтобы проверять const модификатор доступа при вызовах функции, то есть, подставляя переменную аки шаблонный аргумент, как это делает Rust — Страуструп просто выдал что попало, «я свое дело сделал, в стандарте отметился, начальству транслятор продал — а вы дальше любитесь как хотите, бг-г-г».

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

byko3y ★★★★
()
Ответ на: комментарий от alysnix

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

Да, разрабы Qt обмазали свои контейнеры прокладками по самое небалуй, читать сорцы невозможно.

byko3y ★★★★
()
Ответ на: комментарий от x86_64

Именно в модулях можно сделать анализ перекрестных ссылок

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

byko3y ★★★★
()
Ответ на: комментарий от Siborgium

Какое отношение строки-массивы имеют к дополнительным блокам памяти?

Сколько нужно дополнительных блоков, чтобы выделить std::shared_ptr<std::string> ? Два-три.

«двойные указатели» это массив из указателей на ноды. Такой дизайн выбран в связи с необходимостью предоставить требуемые стандартом гарантии. То, что ты хочешь, называется flat_map/flat_set и является другой структурой данных

Здрасьте, а кто стандарт пишет? Моя мамка набезобразничала? Я лично (а также соавторы Boost) писал интрузивные хэш-таблицы, в которых знанения хранились прямо в таблице. И почему-то нам не хотелось написать свой стандарт, который бы нам помешал это сделать.

Утечка ресурсов, отличных от памяти, ничем не отличается от утечки памяти, а GC от нее никак не защитит

Повреждение памяти намного, НАМНОГО опаснее, чем просто утекшие ресурсы. Именно поэтому GC на голову выше любого RAII, именно потому в ряде ниш за C++ сразу бьют по рукам. Выполнив некорректную последовательность деструкторов RAII может выстрелить себе в ногу, а GC — нет. С GC потом уже можно опционально спокойно поотлаживать утечки.

кто будет проверять, что в union лежит корректное значение, кто будет проверять, что

Я про union уже отвечал, я считаю его серьезным изъяном Си - его не должно было быть в языке в таком виде. Сейчас это тупо примитивный сахарок для расчета выравнивания структуры - этого сильно, сильно меньше, чем нужно для высокоуровневого программирования.

byko3y ★★★★
()
Ответ на: комментарий от rupert

Это потому, что если у тебя есть неконстатный контейнер, то взять на него константный итератор было бы очень неудобно без cbegin

Да, любые попытки написать что-то с const приводят к тому, что писать приходится всё по два раза: с const и без const.

byko3y ★★★★
()
Ответ на: комментарий от eao197

На момент появления Rust и Go была точно такая же ситуация: уже была куча языков разной степени продвинутости, распространенности и востребованости

Go упал в почти пустую нишу, как ни странно. На мой взгляд, Java является худшим из менйстримовых языков, C# был win-only или около того. Написать что-то быстро, с гарантиями работоспособности, и с хорошей производительностью было тупо не на чем. Google до этого использовал Java, и впечатления у них были примерно как у меня. По сути, Go — это Java, сделанная по-человечески.

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

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

byko3y ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.