bindings,mangling)
и гуглила соответственно
"how is oop implemented in C++"
"how do classes work under the hood in C++"
"how does compiler compile oop code in C++"
Но все ссылки которые дает гугл это СЕО-пропихнутые сайты-сборники-туториалов про основы ООП с нулем деталей о его реализации.Может кто-то знает хорошую статью или раздел книги?...
Привет. На разных платформах по разному. Для линукса x64 релевантна вот эта реализация https://itanium-cxx-abi.github.io/cxx-abi/abi.html
Так же можешь глянуть код библиотек libsup++ и libcxx-abi. Там есть всякое про RTTI
Да,я слышала что это implementation defined,но ведь у всех должна быть примерно одинаковая реализация.У C,насколько я знаю,тоже нету ABI,но в большинстве своем его имплементация варьируется слабо.Спасибо за ссылку)
А зачем тебе это всё?
Но,блин,как программировать на языке с низкоуровневыми возможностями не зная что происходит на уровне этих низкоуровневых возможностей?Vtables вот напрямую влияют на размер структур и классов вообще
А в чем в С заключается имплементация?
Очень правильная позиция. Я тоже не мог нормально программировать, пока не разобрался как всё работает под капотом
ну,например конвенция вызова функций - порядок аргументов,передаются в стеке или в регистре,еще выравнивание и упаковка структур
Конвенции вызовов, организация стека и тд
Так и программировать, тебе это всё не обязательно знать, тебе нужно знать лишь эффект от этого, гарантии языка, где они есть, и где их нет.
ой,вот я такая же)Без этого постоянная неуверенность.Легче думаю понять причину чем заучивать множество следствий из нее...
Нет, это не правильная позиция. Это вовсе не обязательно знать. Можно изучать, да, но не обязательно
Не обязательно, но это отличное подспорье. Для большинства задач не надо знать как работают кеш линии или устроены числа с плавающей точкой, но это не значит, что это ненужные знания
Это все легче запомнить когда знаешь как оно устроено,тогда и зубрить не придется многое.Я вот поэтому и люблю С,там все прозрачно и в подавляющем большинстве случаев знаешь как и что будет делать машина,я сейчас учу С++ и хотелось бы иметь такое же понимание
Если хочешь стать гуру, то обязательно
Вот. Нет никаких стеков и регистров в С. И ты опять ошибку делаешь, это тебе не нужно знать, а ты учишь и затем делаешь неверные обобщения
"У всех должна быть примерно одинаковая реализация"... Кому эт она должна?)
В стандарте нету,но если программист С не знает что такое стек и регистры я очень сомневаюсь что его кто-то после этого откровения будет слушать.Языки все таки в реальном мире работают и на реальном железе.Чем язык ближе к нему тем больше с ним нужно считаться
Более того, хорошо бы знать как работает железо и хотя бы основы микроэлектроники
реализовано на конкретной платформе/компиляторе? как выше отметили в линуксе манглинг берется итаниумский. майкрософт будет все по-другому может будет полезно: https://youtu.be/SShSV_iV1Ko http://scrutator.me/post/2014/06/02/objects_memory_layout_p2.aspx
Не, если это даёт тебе больше уверенности, то на здоровье, изучай. Но не надо обобщений
Странное заявление. Как знание основ микроэлектроники (а что тут подразумевается под основами) поможет?)
знание работы железа нужно лишь когда пишешь под конкретную платформу, в противном случае - нет
pn переходы, полевые и биполярные транзисторы, логические гейты
это особенность стандартов си, си++. в том что они определяются через абстрактную машину, оттуда же ub. действительно зачем ограничивать возможные оптимизации на конкретных архитектурах?
От этих основ без дальнейшего изучения толку - 0
нет,ну понятно что компиляторы С есть чуть ли не для ЭВМ Третьего Рейха где и байт не 8 бит,но сейчас все архитектуры схожи в реализации и операционные системы можно пересчитать по пальцам одной руки слесаря...И многое в С становится понятным,как и многие возможные ошибки,сайд эффекты,и неожиданные результаты если знать как он устроен 👀
Я не сомневаюсь, что будет слушать, и на работу возмет. Знания самого языка и например алгоритмов или математики на порядок более ценны, чем то как так стек и регистры устроены
Да,но лично я например не собираюсь писать под PDP-11,да и большинство думаю тоже)
Да никто не обобщает. Можно программировать и не быть хакером железа и abi. Но когда прилетает непонятный дамп с крешем на редкой платформе почему то зовут того парня, который может посмотреть на хекс и увидеть там vtbl. Программирование это лишь один из навыков инженера-разработчика
Давай вернёмся к исходному вопросу. Потому и нет материалов, или мало, что при обучении тебя хотят учить не реализации, а самому языку.
Первый раз слышу чтобы такого кто-то взял 😝 Если бы детали реализации были не важны,то его бы и на позицию С не нанимали
хах. все еще обсуждают, нужно ли требовать дополнительный код для интов (назовите архитектуру где не так)... и забыть о -fwrapv
Мда, это вообще зашкаливающее по бредовости заявление..
Аргументов, как обычно, не будет
Мои были проигнорированы :)
котлеты с мухами смешали, хех зависит от позиции и стека и еще 100500 параметров
С и С++ то часто используют где нужно крайнее быстродействие,а его то не обеспечить без знания о внутреннем устройстве.Можно и про дата локалити и кэш забыть,но я не думаю что в условиях создания производительного кода это одобрят
Твои какие-то невнятные )
Очень даже внятные - не поможет C++ разработчику отдельно взятые знание физики pn-перехода, аналоговой схемотехники и прочего вплоть до совсем не основ микроэлектроники
Я с тобой не согласен. Чтобы быть гуру, надо знать про кеши и прочее.
Спасибо большое)Конечно для MSVC хотела бы,но линуксовый тоже хорошо 😊
А можно более конкретный список хотелок?
C++ разработчик это человек, который разрабатывает C++. В реальном мире у разработчика язык это лишь инструмент. Хороший разработчик должен обладать разными инструментами. Но так же он должен владеть предметной областью и хорошо понимать железо под которое разрабатывает
Ты на автомобиле ездишь? Как работает ТНВД расскажешь?
Я там аккуратно намекнуть пытался, что разрозненные знания из разных сфер бесполезны сами по себе
Я в свою машину турбину свапнул, сам поменял всю подвеску, тормозную систему и учусь програмиировать ECU
Это заблуждение. 90% быстродействия даёт алгоритм решения задачи а не язык
А,ну,если конкретнее,то early late binding,vtable,mangling,возможно какие-то то еще детали о которых я не знаю,то как именно компилятор ООП компилирует,извиняюсь за тавтологию)MSVC компилятор в частности)
В msdn поищи, кстати. Там можно найти такие лоу левел детали
омайгааад,разница в быстродействии одного и такого же алгоритма на C++ и питоне будет десятки а то и сотни раз.Если бы твоя позиция была верна то никто бы не писал на C++ и С
Не надо. Программист не управляет кэшем, не может на него влиять.
Но может организовать структуры данных так, что бы повысить кеш локалити
Я бы сказал, что сипп это больше инструмент чем язык. Потому что как язык в силу эволюционного развития он так себе, но как инструмент до сих пор не имеет равных в некоторых областях.
"Пощупать" руками в WinDbg + MSDN Вопросы манглинга и связывания описаны скорее из разряда "оно существует". С точки зрения компиляторной реализации - сорцы MSVC закрыты, я бы глянул в LLVM
Ну это да. Правда я не видел от него профита, в отличии от банальной замены aos на soa.
С++ и питон - это очень неудачный пример. Не потому что с++ такой быстрый. Просто питон очень медленный
Системный влияет, например на x86 в маппингах виртуальной памяти можно указывать что страница не должна кешироваться.
Так это... Почему ещё не взят в руки мануал по асму?!
я писала на FASM но это трудновато хд
Мне только интересно, какое это имело отношение к спору - он вроде о прикладном ПО...
мне кажется удачный который как раз показывает что от языка многое зависит и все языки разные как раз,а есть еще медленнее питона,а есть C# где например GC имеет stop-the-world и если на нем писать игру он может каждые 1,5-2 минуты фризы выдавать ощутимые.реальный мир все таки
Как по мне более муторно. Но читать асм часто приходится. А писать на асме интереснее под эмбедед и всякое ретро. Под z80 вообще кайф )
На сипп о таком можно задуматься, когда пишешь ос. В случае питона — никода.
Логично - на Питоне ОС не пишут
Это исключение. Самый тупой и медленный язык взят. Это нельзя за правило взят ну совсем никак.
У меня было много макросов правда,получалась как на очень странном Си,зато все очень прозрачно) https://ibb.co/7b1dq8v
Под pdp11 еще лучше. 16 бит, относительно ортогональная архитектура, удобная адрессация. А zilog z80 это по сути интелловксий 8080 (есть второй набор регистров, и с прерываниями получше емним)
Надо бы попробовать. Всё это отличная разминка для мозгов
Полезно знать, чтоб понять и простить си.
ну любой другой тоже подходит,у джава вот все объекты в куче хранятся и там плохо с дата локалити,про языки GC я уже упоминала с их фризами.С++ как правило в 1,5-2 раза быстрее чем C# и в 2-3 быстрее чем Java.2-3 раза в производительности это пипец большая разница если приложение ресурсоемкое.Если хочешь писать быстрый код для железа нужно знать детали железа,это же очевидно.Нет,ну если у вас там простенькое приложение или программа которая и так ест 1% процессорного времени то оптимизировать это ни к чему,но когда перфоманс важен то тут уже ясное дело обо всем этом нужно задумываться!
А потом наступит прозрение, и начнёшь понимать и прощать плюсы
Нет не подходит.
Подходит)По скорости и возможности оптимизаций с С++ сравним только С и Rust.Да и другие языки иначе бы не пытались изо всех сил оптимизировать и добавлять фичи в язык для более оптимальных операций.И в скорости они уступают
Паскаль еще, лазарус вполне пригодная штука и работает всё хорошо. То что язык не очень популярен, не делает его медленным, наоборот, пишешь по старому, почти как на С, но ООП там уже есть.
Это чертовское враньё.
Нет,это очевидная правда которую почему-то знают все кроме вас,достаточно бенчмарки погуглить.Хотя вы уже троллите просто =w=
это кстати всё равно не совсем корректно, быстрее или медленнее что-то от чего-то, не сам "С++", это было бы верно, если бы у С++ был один единственный компилятор
Да,компилятор крайне важен,лет 40 назад и Си был чересчур медленным и программисты всячески подсказывали ему через инлайны и register,но тут еще и сама философия языка форсирует скорость - zero overhead abstractions и don't pay for what you don't use
не С был медленным, а железа не было мощного и быстрого
Ну да, ты ж сама небось 40 лет назад компиляторам патчи писала...
он не крайне важен, это жизнь С++, полная зависимость от реализации компилятора, а не наоборот
к счастью нет,но некоторые слухи с тех времен до нас дошли 🤗
всё крайне просто, класс/ структура это просто неймспейс, в котором объявленные функции будут ещё и получать при вызове из инстанса класса неявным первым аргументом указатель this на инстанс класса (статические методы это просто функции) неймспейсы же в свою очередь (как и шаблоны как и перегрузки как и специализации и т.д. ) все связаны с манглингом (Это по сути основа на чём стоит С++ ), заключается вся техника в том, что компилятор модифицирует имя(идентификатор) дополняя его неймспейсом / классом / функцией где декларировано имя аргументами шаблона / типами аргументов функции / условиями if constexpr (неявный шаблон )
Никакого манглинга в языке нет. Он появляется только в объектном коде, когда линкеру надо символы связывать.
никакого манглинга нет, но всё на нём строится угу
А что на нём строится?
реализация неймспейсов и перегрузок -> шаблонов функций и операторов -> шаблонов классов структур -> и т.д.
Формально, Илья прав - Стандарт С++ действительно не определяет реализацию связывания :)
я это тоже упомянул
Ну я тоже неочень понимаю, но тут пишут так
Спасибо большооооое за такой подробный ответ!Мне еще тут рассказали про Itanium ABI,было бы классно если бы все компиляторы под x86 его придерживались)А насчет наследования и виртуальных таблиц...если A : B и в B есть виртуальные функции,то в VMT класса A в самом начале будут стоять указатели на виртуальные функции класса B,а потом за ними уже A?
чаще всего они перезаписываются
Увы, но именно язык Напиши просто рандомную генерацию 10000 чисел Питон управится за пару минут Плюсы за пару секунд
А потом подергаем rdrand из ассемблера...
Питон управится с той же скоростью что и плюсы при использовании нужной либы)) Jit Numba
Питон - это очень особый случай...
Что насчёт перла?😏
С перлом всё гораздо проще, но с ним другие проблемы
Да ты что, а то, что арифметические операции на нём выполняются медленнее, чем даже на питоне это не проблема? Хотя свою задачу по работе с текстом он выполняет на отлично и главная проблема перла это перл 6)
Обсуждают сегодня