LINUX.ORG.RU

Почему все же с++ такой сложный язык?

 ,


3

4

С++ – сложный язык. Хоть это для каждого по разному и тд, но он очевидно сложнее большинства (всех?) высокоуровневых языков программирования. С другой стороны он очень быстрый и дает тотальный контроль.

Теперь вопрос: должен ли язык быть априори настолько сложным для достижения мощи как в с++ или же так просто исторически сложилось (ака историческая несправедливость)?

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

один опытнейший C++-разрабочик написал пронзительное

это деадфуд опытнейший чтоли? спасибо поржали.

С++ – сложный язык.

Он очень старый. Они же не могут взять и создать новый С++«2» - это было бы провалом, вот и возятся. Тем не менее раст ничем не лучше, лишь компилятором запрещающим тебе сделать сепуку.

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

Пресловутая контекстная зависимость (одна и та же лексема в разных контекстах означает разное, например «*» или const).

Это плюс, а не минус.

Жуткое автоматическое приведение типов.

Это проблемы сишки. В С++ нет автоматического приведения типов.

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

Разница однозначно и простым языком описана в стандарте.

Кстати вот про истоки синтаксиса указателей:

и усложнили понимание кода программы до «мля, ну почему так сложно-то?».

Вообще насрать, какие у него истоки. У указателей есть один объективный косяк – кривое поведение SomeType* a, b. Никаких проблем кроме этой ни у кого с ними нет.

Более-менее вменяемое объяснение здесь

Невменяемое объяснение. Никто так не пишет, такой проблемы не существует.

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

Да ладно? По ссылке «разоблачается» неизвестно откуда выдернутое «Это его свойство - изменять значение операнда уже после использования». Ни разу в жизни не встречал человека, который так объяснял бы семантику префиксного инкремента. Цитируемому пациенту – срочно в школу.

Шаблонная магия

Без «шаблонной магии» нет С++.

которая должна была добавить достаточно простую вещь: возможность типонезависимости переменных языка

Не должна была.

в связке с предыдущим пунктом надо вводить понятия rvalue и lvalue.

Которые существуют во многих других языках программирования, включая чисто скриптовые. Для прозрения предлагаю почитать исходники, например, awk.

Вот, посмотри как кукушка хвалит петуха за то что хвалит он кукушку

Таких видео тысячи для любого ЯП.

Но это академическая среда так коверкает людей

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

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

Переиздание книг Столярова по программированию (комментарий)

с фором удачно получилось - ибо макра которую погрузили в язык

ваще Томсон/Ричи круто смогли из обыденного строчного парсера получить почти топ-даун.

но без его(топ-дауна) ограничений

т.е Томсон реально крутой инженер - и с точки инженерии(а именно решения проекта заказчика) - к GoLang нет претензий :)

они и получили топ-даун: man TMG : McIlroy’s TMG compiler-compiler in portable C

TMG – Compiler writing language

Oral History interview by Mahoney with McIlroy
MSM: Was B ever used in Multics?

McIlroy: No.

MSM: So, that history of BCPL to B to C, is it all here?

McIlroy: All here.

McIlroy: And TMG fed into that too. Some of things like the two-address assignment operators were in TMG here first and then were adopted by B and by C. I can?t say I invented them because they also came from ? they were also in Algol 68 at the same time. B is where the unusual express? uh, declaration syntax of C came from. That was Ken?s invention, that the declaration should look like any? should have the same syntax as an expression.

MSM: Since we?re on C. One of the? I?ll ask Dennis this when I get to it, but one of the features is, that struck me about C was when I was writing a LISP interpreter for ? in it. This property of C, of always? of any statement bringing back a value, in the type, so that all operators have values, and so I found that at a certain point my core C LISP was beginning to look like LISP expressions, and at a certain point it just seemed automatic to go over to a LISP library.because I was just stacking parenthesis in C. Where did that come from? Is that part of B? Or ? the notion that all operators have values?

McIlroy: Yeah. It was also in Algol 68. In BCPL, which came out of CPL, they had the very, very strong distinction between functions and commands. An assignment was a command. So, they did not have? I do not think the assignment was an operator in the expression. But, it was in Algol68. So, that was in? So that happened sort of everywhere at the same time. In fact, the first place I saw it was McClure?s proposal called Linear C, which was way before the language C. Just liked it because it sounded nice. Like after Linear A and Linear B.

MSM: Oh I see, I see

McIlroy: It was an obscure looking language and it was linear, because you wrote tremendous long expressions.

MSM: Must have placed you on the borderline between a procedural and functional language?

McIlroy: Yes. It did. And roughly speaking what it had was a "break" and a "continue" statement. "Continue" simply went back to the last parenthesis, and "break" simply jumped over to the next one, and those were the major controls, plus an "if" of course, those were the major controls in the language. So, there wasn?t an actual key word "for". Just the fact that you said "continue" meant you would jump back.

EPL это диалект PL/I написанный на TMG под Multics, ранняя реализация.

потом self-interpreter, self-compiler PL/I забутстрапился в какой-то XPL:wiki XPL:site XPL:teampli

а одна из ранних реализаций PL/M была на фортране написана.

anonymous
()
Ответ на: комментарий от qulinxao3

с фором удачно получилось - ибо макра которую погрузили в язык

диалекты, тысячи их :

PL/I Extensions: APAREL (A Parse Request Language) a PL/I extension to add BNF parsing routines. GASP (Graph Algorithm and Software Package) a PL/I extension for programming graph algorithms. GPL/I (Graph Programming Language/One) a PL/I extension for handling graphs as a fundamental datatype.

ничего удивительного: у Eberhard Sturm было про реализацию PARSE диалекта из REXX (скриптота но PL1) на препроцессоре PL1 (можно было сформировать строчку и подать её компилятору).

гораздо более препроцессорное чем сишное с #define и гомоморфным стрингованием конкатенацией.

но гораздо менее чем полноценное Multi-Staged Programming типа того же MetaOcaml где типизированное лямбда исчисление позволяет делать типизированный AST и конструировать эти свои Brackets, Escape, Run в мультистадийные корректные well-formed контролируемым образом конструируемые макросы – а не просто строки.

в квотезы!

а кастаньеда страуструп об этом ничего не писал (c) !ъ.

вообще, он наверное и не ожидал такой популярности для своей симуляции ядра в модульное через Simula67-BETA-подобное ООП. и тут ему ВНЕЗАПНО попёрло.

anonymous
()
Ответ на: комментарий от qulinxao3

TMG:examples:brnfk2c.t

брейнфак на TMG.

EPL наверно алголистей будет.

а если интерпретатор лиспа на TMG написать, то вааще…

anonymous
()
Ответ на: комментарий от qulinxao3

а вот тебе ещё в тему Rule 110:

0ISC на гомоморфном шифровании cryptolec

читаю тут Gimpel_J.F._Algorithms_in_SNOBOL4.djvu.

немного приоткрыто про гомоморфизмы. tr, replace можно выразить подстановками и перестановками. далее в духе снобола с first class object=pattern для pattern matching-а по строкам на этом реализуют машину перестановок и марковские алгорифмы.

далее монады это моноиды в категории эндофункторов структуры типа списков, строк, стеков. и на всём этом можно изобразить O1, O2 из cryptolec.

ну или реализовать в/на Rule 110.

то есть гомоморфизмы как механизм pattern matching-based для марковских на которых можно тоже реализовать какой-нибудь eval лисповый.

макры на марковских, ога.

anonymous
()
Ответ на: комментарий от bhfq

это деадфуд опытнейший чтоли? спасибо поржали.

он там свой личкрафт дописал наконец, бросил что ли – или как?

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

В мире уже давно Unicode, а вы все смотрите на все эти ANSI помойки как на божества.

он там свой личкрафт дописал наконец, бросил что ли – или как?

без понятия что это и зачем кому нужно.

bhfq ★★★★★
()
Последнее исправление: bhfq (всего исправлений: 2)

Почему все же с++ такой сложный язык?

by design. вообще проблема не в том что он сложный – а в том, что в нём эта сложность структурирована по-дурацки.

ЯВУ называется низкоуровневым, когда требует подробной информации о несущественном.

в этом смысле ООП в С++ – низкоуровневое. template а не generic – низкоуровневое. С с ссылками и классами – низкоуровневое.

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

например, в аде выбраны tasks и полиморфизм модулей. из этого уже можно строить какую-то компонентную ибо модульная и конкурентную ибо tasks с рандеву систему, описать её на уровне процессов (tasks). потом навертеть семантику с SPARK и ASIS. и ограничить фичи рантайма прагмами, верифицируемо и контролируемо.

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

высокий уровнень, говорили они. ога.

anonymous
()
Ответ на: комментарий от bhfq

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

хотя он последнее время вроде по хаскелю упарывается.

anonymous
()
Ответ на: комментарий от bhfq

В мире уже давно Unicode, а вы все смотрите на все эти ANSI помойки как на божества.

нет – мы смотрим на Unicode помойку как на помойку.

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

неукоснительного соблюдения взаимоисключающих параграфов

пол шестого утра, я ржу в голосину, что ты делаешь, сцуко))))

anonymous
()
Ответ на: Xintrea, залогинься от anonymous

«%username% залогинься» признак идиота. Дальше - вот хошь верь хошь нет, ни буквы не прочитал.

anonymous
()

Теперь вопрос: должен ли язык быть априори настолько сложным для достижения мощи как в с++

не должен, ибо из сложности не следует мощность. обратное скорее верно – но только как quick and dirty hack, вместо того чтобы упростить правильно.

compicated complexity – громоздкость, трудоёмкость реализации. та самая подробная информация о несущественном.

sophisticated complexity, architectural approach, design principles, rationale – как раз про то, как выбрать главные, существенные принципы так чтобы из них а) остальное можно было вывести б) полученным решением было пользоваться просто.

проблема с индусами триальными ремесленническими поделками в том, что premature optimization is evil вот это всё. а до state of art и собственно, искусства – минимализма, но не примитивизма; конструирования смыслов из принципов вместо нагромождения костылей – не хватает.

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

Опытность меряется тем, что ты знаешь, что к буферу, полученному по сети, нельзя обращаться как к содержащему объекты, т.к. их там не было создано, согласно объектной модели C++?

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

Странный критерий, как минимум очень специфичный. Иногда к такому буферу вполне можно обращаться как к содержащему объекты. Также иногда алгоритм со сложностью O(n^2) лучше чем алгоритм со сложностью O(n*log(n)). Жизнь вообще штука сложная и интересная.

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

Иногда к такому буферу вполне можно обращаться как к содержащему объекты.

В полнолуние?

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

В полнолуние?

Какой же ты остроумный, прямо шик и блеск! Тебя там не распирает от чуустуа собственной значимости? А так бы ты подумал о том, когда это возможно. Например, если у тебя объекты это всего лишь врапперы над POD типами, например int. У таких объектов конструктор это всего лишь инициализация, так что int можно просто привести к такому объекту. Не самый гениальный ход, конечно, просто демонстрация пробела в твоем категоричном утверждении.

А что же ты не спрашиваешь в своей «остроумной» манере когда это O(n^2) лучше чем О(n*log(n))? Или для тебя это просто набор буковок?

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

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

Тебя там не распирает от чуустуа собственной значимости?

Есть немного.

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

Демонстрировать лучше кодом, слова «int можно просто привести к такому объекту» можно понимать по-всякому.

А что же ты не спрашиваешь в своей «остроумной» манере когда это O(n^2) лучше чем О(n*log(n))? Или для тебя это просто набор буковок?

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

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

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

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

Демонстрировать лучше кодом, слова «int можно просто привести к такому объекту» можно понимать по-всякому.

Ну так возьми и продемонстрируй кодом, где же я не прав.

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

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

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

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

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

Дедфуд где-то не так использовал буфер с данными, полученными по сети?

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

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

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

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

Есть такая практика в научной среде - писать статьи для галочки. Мне кажется в комитете тоже есть такая практика.

— В цепепе слишком много UB, комитет, убирай UB!
*Комитет убирает*
— Вот комитету делать нечего, такое UB фиксить!
— …

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

Опытность меряется тем, что ты знаешь, что к буферу, полученному по сети, нельзя обращаться как к содержащему объекты

Вообще-то, если ты будешь получать данные по сети, то будешь передавать в соответствующую функцию зараннее созданный буфер на СВОЕЙ стороне, поэтому проблему ты просто придумал из ничего. Если по сети к тебе идет структура struct Anything, то создай её и отдай на запись, соответствующее апи принмает либо char, либо byte, которым позволено алиасить что угодно. Видимо, ты в теме плаваешь, но это не мешает тебе вынести свой экспертный вердикт о цпп.

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

Если по сети к тебе идет структура struct Anything, то создай её и отдай на запись, соответствующее апи принмает либо char, либо byte

И это до недавнего времени было UB.

которым позволено алиасить что угодно.

strict aliasing не при чём.

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

И это до недавнего времени было UB.

Это не было никаким UB, всегда можно было, недавно только std::byte добавили.

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

Это не было никаким UB

Ок, какие параграфы описывают поведение кода, который пишет поверх структуры байтами невесть откуда взявшимися?

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

Быстро читаешь) Я потом удалил же. Потому что моя первоначальная критика была неправильной - удаляя UB комитет делает правильные вещи. Но все равно там все не так просто. А подробнее погружаться у меня просто реально времени нет сейчас.

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

Я ссылку на цппреференс дам, там один фиг почит голая копипаста стандарта, лень сейчас стандарт копать:

Type aliasing

Whenever an attempt is made to read or modify the stored value of an object of type DynamicType through a glvalue of type AliasedType, the behavior is undefined unless one of the following is true:
...
    AliasedType is std::byte (since C++17), char, or unsigned char: this permits examination of the object representation of any object as an array of bytes.
...
pavlick ★★
()
Ответ на: комментарий от pavlick

Я спрашивал про то, как определено поведение, а не про то, в каких случаях оно не определено.

this permits examination of the object representation of any object as an array of bytes.

Не permits, а doesn’t prohibit. С доступом к объектам через char/byte сейчас в C++ явные проблемы. (Раньше были неявные).

anonymous
()
Ответ на: комментарий от qulinxao3

Переиздание книг Столярова по программированию (комментарий)

законы Паркинсона

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

у кода(кривого) который наряду с исполнением на троечку(Си) основной_задачи - оставляет кучу удобрений для участников биогеоциноза.

sic my duck

совершенный код против дилеммы инноватора

говноподдерживающие vs. говноразрушающие говнотехнологии.

крч У кривого_кода больший мультипликатор.

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

насчёт удобрений участнегов биогеоценоза.

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

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

и подумалось мне, внезапно: что если это всё и не прогресс а совсем даже и деградация. разумное падение.

история развития экономики и торговли – это история говна.

в прямом, непосредственно в ощущениях – смысле.

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

если война это экономика другими способами, в корне причин всех войн всегда лежит идеология + экономика.

на примере фритрейдерства и бомбления портов с канонерок это нагляднее всего заметно.

а чем ведутся войны? порохом. на основе серы и селитры. то есть, опять таки, в прямом смысле: на основе мочи и говна.

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

ну и где же собственно прогресс. в экономику нового типа, в игру с положительной суммой.

текущая экономика это экономика говна. и биогеоценоза производящего круговорот говна в природе посредством говна, говноделов, говнотехнологий, говнофреймворков и говноидеологий.

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

пусть лучше уж на удобрение переводят. выращивая с положительной суммой.

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

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

видать гумус природе требуется.

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

Я спрашивал про то, как определено поведение, а не про то, в каких случаях оно не определено.

Если не ЮБ, значит определено. А сам как думаешь, какое поведение у *char_ptr=3? Хз, к чему ты вообще цепляешься, по-моему все очевидно. В справочнике знают, что у них в примерах код кривой?

...
    std::uint32_t n;
    if(raw.read(reinterpret_cast<char*>(&n), sizeof n))
        std::cout << std::hex << std::showbase << n << '\n';
...
pavlick ★★
()
Ответ на: комментарий от pavlick

Если не ЮБ, значит определено.

«the behavior is undefined unless one of the following is true» ≠ «the behavior is defined if one of the following is true», как бы.

А сам как думаешь, какое поведение у *char_ptr=3?

Зависит от того, как char_ptr был получен.

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

Это от наивности.

В справочнике знают, что у них в примерах код кривой?

read это библиотечная функция. Библиотечный код может «магически» работать даже если ты сам не можешь написать аналогичный код на обычном C++.

Почитай это.

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

«the behavior is undefined unless one of the following is true» ≠ «the behavior is defined if one of the following is true», как бы.

Бред. Это работает во всех компиляторах –> наплевать, что написано в портянке.

Зависит от того, как char_ptr был получен.

Полная чушь.

Это от наивности.

Нет.

read это библиотечная функция. Библиотечный код может «магически» работать даже если ты сам не можешь написать аналогичный код на обычном C++.

Шизик, как, по-твоему, написан read? Любой библиотечный код пишется на том же C/C++. Если нельзя написать аналогичный код, то как эту функцию написали?

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

Почитай это.

А ты его сам читал? Он какой-то устаревший. Смотри что там пишут:

int a = 420;
char b = *reinterpret_cast<char*>(&a);

value of the pointer is unchangedand therefore it points to the original object. When the lvalue-to-rvalue conversion is applied to the initializer expression of b, the behavior is undefined as per[expr.pre] p4 because the result of such a conversion would be the value of the int object (420), which is not a value representable by char.

т.е. вся проблема здесь в том, что инициализируем char int’ом. Вообще-то это уже не актуально ибо это сделали определенным как с беззнаковыми целыми:

If the destination type is signed, the value does not change if the source integer can be represented in the destination type. Otherwise the result is implementation-defined (until C++20)the unique value of the destination type equal to the source value modulo 2n
where n is the number of bits used to represent the destination type. (since C++20). (Note that this is different from signed integer arithmetic overflow, which is undefined).

Там ещё речь про адресную арифметику, честно, я не очень понял в чем там проблема вообще:

usingT=unsigned char*;
int a=0;
T b=reinterpret_cast<T>(&a);
// Pointer value unchanged, still
// points to the int object 
T c=++b;
// UB, expression type differs
// from element type

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

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

Любой библиотечный код пишется на том же C/C++.

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

anonymous
()
Ответ на: комментарий от pavlick

А ты его сам читал?

Немного даже участвовал в написании.

Смотри что там пишут: … т.е. вся проблема здесь в том, что инициализируем char int’ом.

Ты абсолютно не понял, что там написано.

Вообще-то это уже не актуально ибо это сделали определенным как с беззнаковыми целыми

Это совершенно не при чём.

Там ещё речь про адресную арифметику, честно, я не очень понял в чем там проблема вообще:

В этом.

возможно что случайно отломали и уже пофиксили

Не пофиксили.

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

наплевать, что написано в портянке.

Стандарт надо читать, а не свои вонючие портянки.

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

В этом.

Ну мы же понимаем, что речь о том, что нельзя итерироваться по массиву Derived имея на руках указатель на Base, как бы логично. Если что-то там в стандарте не ясно написано, то допилят. Запись/чтение через чар разрешена в стандарте явно, никто не будет запрещать арифметику, это просто бред:

If a program attempts to access (3.1) the stored value of an object through a glvalue whose type is not similar (7.3.5) to one of the following types the behavior is undefined:
—(11.1)the dynamic type of the object,
—(11.2)a type that is the signed or unsigned type corresponding to the dynamic type of the object, or
—(11.3)a char,unsigned char, or std::byte type

access - (execution-time action) read (7.3.1) or modify (7.6.19, 7.6.1.5, 7.6.2.2) the value of an object

Ты абсолютно не понял, что там написано.

А о чем там тогда первая проблема?

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

Ну мы же понимаем

Кто мы-то? Не надо меня в компанию жопочтецов записывать.

речь о том, что нельзя итерироваться по массиву Derived имея на руках указатель на Base, как бы логично.

Ты опять ничего не понял. Речь не только о случае с Derived и Base классами. Это частный случай.

Если что-то там в стандарте не ясно написано, то допилят.

Ну когда допилят тогда допилят? А пока работа с представлением объектов с ног до головы обмазана UB.

Запись/чтение через чар разрешена в стандарте явно

И чтение через чар даёт «интересные» результаты, о чём написано в том пропозале. (Ещё более интересные даёт запись).

никто не будет запрещать арифметику, это просто бред

Тем не менее, она запрещена.

А о чем там тогда первая проблема?

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

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

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

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

А вы уже виделись? Как встреча прошла, лангуаге лангуагили?

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

Ну когда допилят тогда допилят?

Тут в конце должна была быть точка.

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

Объяснять нужно не разницу между ссылками и указателями, а разницу между объявлениями T v = e; и T& r = e;. (Где T — не ссылочный тип). Необходимость объяснять разницу между ссылками и указателями возникает у тех, кто сначала даёт пэтэушное «определение» вроде «ну ссылка это типа указатель только он сам разыменовывается))0)0»

Это прелестно. Язык просто бомба, синтаксис огонь. А почему не &T r=e? Как запомнить, слева или справа апмерсанд фигачить? А это не будет адресом? Нет, но адрес будет неявно фигурировать? А где? А, на это не надо обращать внимания, но надо. А что будет если T окажется ссылочным типом? Как так переменная автоматически неявно приводится к ссылке в вызовах функций если в прототипе ссылка? А при наследовании ссылка и переменная - это разные вещи? А почему? У вас там неявно, а тут явно, где закономерность? Ойойой, сюда еще и const можно писать. В разные места? С разным контекстом? Боженьки вы ухитрились столько противоречий напихать в выражение из 5 знаков. Но зачем?

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

А почему не &T r=e? Как запомнить, слева или справа апмерсанд фигачить?

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

Нет, но адрес будет неявно фигурировать? А где?

Нигде.

переменная автоматически неявно приводится к ссылке в вызовах функций если в прототипе ссылка

Ты сам такую чушь придумал или этому в ПТУшных методичках по C++ учат?

anonymous
()
Ответ на: комментарий от bhfq

это деадфуд опытнейший чтоли? спасибо поржали.

А на самом деле нет? А тоя хотел учить плюсы, но почитав статью засомневался …

Владимир 123

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